Судя по этому рейтингу, Cobol находится на одном уровне с Kotlin (который используется едва ли не в большинстве всех Android приложений, который является рекомендованным по-умолчанию для Gradle, и который входит (вместе с Java) в список языков, которые используются в документации Spring.
Собственно, есть подозрение, что этот рейтинг очень плохо отражает реальность...
Какие есть команды, чтобы прочитать последнее значение из observable RxJS?
Подобные вопросы на эрудицию, конечно же, не очень помогают найти именно хорошего синьора, тут спору нет. Вот только я видел кучу раз то, как люди заваливались на очень простых задачах на написание кода (буквально "найдите индесы всех букв 'а' в строке, выбирайте любой язык), хотя резюме претендовало очень крутого специалиста.
А потому, вопросы на live coding очень хороши (если берут не чистого управленца), но вопросы на глубокое знание одной конкретной библиотеки - это очень странно (если только человек не написал, что является экспертом в ней, тогда стоит проверить, как кандидат определяет слово эксперт).
Как проходить подобные интервью пока не понял, задают десяток подобных вопросов и всегда находят что-то что не помнишь здесь и сейчас и что по их мнению кодер всегда помнит.
Если в роли предполагается знания языков программирования (ну или определенного), то необходимо показать необходимый уровень, причем каждый следующий включает в себя предыдущий. Условно говоря, джуниор может завалиться на вопросе для мидла, а синьор (и, особенно, тимлид) - нет.
Другими словами, если Вы не пишете код (а потому собеседование будет пройти непросто), то лучше выбирать роли чистого управленца, где будут спрашивать про MBA, попросят показать, как Вы выбираете risk appetite и пр.
они ожидают одинаковой логики от этих абстракций, и в большинстве случаев получают ее.
Я не до конца этого понимаю.. Вот есть у меня Map в переменной. Могу ли я в цикле проверять "есть ли элемент в Map", если число проверок будет столько же, сколько и размер Map? Для HashMap - однозначно, а вот для TreeMap я свалюсь в NlogN (N проверок по logN), плюс в Java будут еще проблемы с нелокальностью памяти (но это, зачастую, уже мелочи).
Аналогично про List - отличный интерфейс, вот только могу ли я спокойно сохранить его в переменную (так как он неизменный, как и 99% List'ов в программе) или нет? А могу ли я добавлять туда элементы (так как это копия) или же я получу ошибку?
Ответы будут только тогда, когда я получу очень узкий интерфейс, который, по сути, будет полностью описывать реализацию.
они более всех ближе к той границе где за гранью хороших практик и все возможных общих советов уже идет сугубо индивидуальные задачи
Мне всё-таки так не кажется. Функциональный подход (для JVM это будет Scala/Kotlin) дает намного больше пользы. Он автоматически покрывает DDD (по сути, DDD из него и выходит), он сразу применяет Open-closed Principle (за счет того, что намного проще скрывать не только классы/методы, но и область видимости переменных) и так далее.
SPR не требует от нас ограничиваться одним методом, он лишь призывает к тому что бы класс, а именно его состояние и поведение, были ограничены одной зоной ответственности
И это очень сложное утверждение, так как, например, можно придраться, что логгирование действий выходит из зоны ответственности, как и проверка входных переменных, а можно сказать, что это не так. Тут очень тонкая философия, которую, с моей субъективной точки зрения, сложно синхронизовать в команде.
Довольно занятно, как в реальных проектах ломаются все озвученные принципы:
каждый класс должен иметь одну обязанность и, следовательно, одну причину для изменения.
И это приводит к разрастанию очень и очень маленьких классов (буквально по одному методу), а потому становится очень сложно понять, что же происходит.
Если в алгоритмах нужно что-то поменять, то у нас нет причин изменять сам класс родитель. И в том и в другом случае это плюс к одной причине для изменения. +1 SRP
Не совсем. Если меняются сигнатуры, то это запросто повлечет изменения в куче мест. Более того, тут используется термин "класс родитель", а потому можно предположить, что предлагается делать наследование. Если так, то добавление нового аргумента в конструктор базового класса поменяет вообще все классы наследники.
Декоратор. Добавляем дополнительное поведение объекту, не меняя внутренности других декораторов и самого класса. +1 OCP
Это очень опасный подход, кстати, так как декоратору придется реагировать на все-все изменения сигнатур методов, плюс сложно будет понять, правильный ли интерфейс используется или нет.
Liskov Substitution Principle - Принцип подстановки Барбары Лисков Объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы.
Если исключить самые-самые простые примеры, это принцип не работает даже в небольших проектах. Несмотря на то, что интерфейс к базе может быть общий, синтаксис запросов будет очень разным (как пример). Несмотря на то, что существует интерфейс List в Java (IList в .Net), в реальной программе всё-таки требуется знать, изменяемый объект или нет, это ArrayList или LinkedList и так далее. Аналогично про интерфейс Map (это может быть и хеш таблица, и дерево).
Interface Segregation Principle - Принцип разделения интерфейса Клиенты не должны зависеть от методов, которые они не используют, в общем, это про правильное разделение интерфейсов.
Принцип разделения интерфейсов говорит о том, что слишком «толстые» интерфейсы необходимо разделять на более маленькие и специфические, чтобы программные сущности маленьких интерфейсов знали только о методах, которые необходимы им в работе. В итоге, при изменении метода интерфейса не должны меняться программные сущности, которые этот метод не используют.
И, в целом, идея даже правильная, вот только даже List, приведенный в пример выше, уже нарушает этот принцип. Собственно, если честно следовать этой логики, то у каждого интерфейса должен быть строго один метод, иначе можно быстро найти пример, когда код нарушает правило.
Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций. То есть, абстракции не должны зависеть от деталей, детали должны зависеть от абстракций.
Это очень спорное правило, на самом деле. Как раз наоборот - если я использую драйвер к базе, я четко осознаю, как он работает. Если я читаю строки из файла, я именно понимаю, как всё будет происходить. Более того, если мы не делаем библиотеку, то мне намного легче видеть, что конкретно вызывается (с поправкой на unit тесты, где могут быть подмены), вместо того, чтобы иметь еще один проект посередине, чтобы каждый раз просить IDE перейти к реализации. Собственно, я привел примеры выше про List и Map.
Более того, если представить, что нам захочется сменить базу данных, то такая мелочь, как смена типов в программе, будет незаметна даже на фоне созвонов и договоренностей с Dev Ops.
На самом деле, основной совет должен быть "код должен легко поддерживать изменения в рамках ответственности проекта".
Условно говоря, если в проекте постоянно добавляются интеграции с другими сервисами, но всегда есть одна и только одна база данных, то можно смело рассчитывать на неизменность базы, но заодно следует готовиться к новым внешним сервисам.
Заодно правило выше будет толкать к написанию правильных текстов, к более читаемым и строгим типам, к наличию необходимой документации и корректного ревью кода.
Парниковый эффект меняет климат - где-то становится теплее, где-то холоднее. Условное таяние ледников запросто приведет к остановке гольфстрима, так что в Гренландии, Исландии, Норвегии и Швеции будет еще холодее.
Заодно запросто климат может поменяться на более засушливый (в некоторых районах), что создаст проблемы с земледелием. Ну или на более влажный, тогда будет больше рекордных наводнений и пр. Понятно, что, если есть возможность магическим образом перенести города чуть-чуть вбок, то проблем бы с теми же наводнениями не было, но, по факту, придется или строить дорогие дамбы, или сносить уже построенные здания (а города очень часто недалеко от рек, ибо в них очень много плюсов).
Также считается, что нарушение течения может стать результатом глобального потепления, поскольку на динамику течения оказывает значительное влияние солёность океанской воды, уменьшающаяся из-за таяния льдов. Возможно также влияние уменьшающейся разности температур между полюсом и экватором при усилении парникового эффекта. Таким образом, «глобальное потепление» грозит Европе катастрофическим похолоданием.
Время от времени хаотическое движение воздушных масс в атмосфере, а также взаимосвязанные с ними тепловые процессы на земле и в воздухе приводят к формированию исключительно крупных облачных объединений, содержащих огромное количество воды, которые накрывают довольно большие территории. В конечном итоге это приводит к обильным и продолжительным ливням. Если естественные водостоки в виде рек и почвы не успевают отводить выпадающую влагу, происходят наводнения. Мощные снегопады образуются практически по такой же схеме
Только для условного котлина вам придется искать кучу разных библиотек - работа с БД
Таких библиотек много, но добавим 1-2 часа на интеграцию.
всякая арифметика с датами, временем, фиксированной точкой
Мне сложно даже сказать, в какой технологии этого нет.
то прежде чем его использовать, вы обязаны провести полный аудит всего кода
В банках уже используется Java, Kotlin, Python, C++ и еще куча всего, если верить вакансиям. Я не знаю, откуда это дополнительно требование.
А потом убедиться, что все это по производительности и потреблению ресурсов не хуже и вам не потребуется в два-три раза больше железа подо все это ставить.
Мне сложно поверить, что современный JVM (с зелеными потоками и пр.) будет медленнее, чем Cobol. Разве есть хоть какие-то свидетельства этого?
И "более читаемым" оно будет только для того, кто этот самый котлин знает.
Это задача на один день для человека, который имеет опыт с другим языком JVM, ну или на 1-4 недели изучения и работы, если человек вообще новичок. Так-то Котлин в вузах изучают, на нем программы пишут уже после первых пары занятий (то есть буквально после потраченных 3-5 часов). Затраты только на поиск специалиста на Cobol будут больше.
а что там такого на этом Коболе написано, что нельзя взять и переписать?
Там нет ничего такого. Это язык полный по тьюрингу, уровень типизации у него низкий и так далее. Честная перепись на условный Kotlin (с корректной типизацией и пр.) не будет сколько-нибудь сложной вещью, да и финальное приложение будет более читаемое.
Основная проблема в том, что на Cobol осталось только дремучее легаси, которое переписать стоит больше, чем бюджет отдела на год. Более того, проблемы (если верить слухам) усугубляются тем, что ряд приложений уже одобрены/сертифицированы (пусть даже выдают не всегда корректные данные), а документация утеряна, так что перепись на любой другой язык несет в себе риск получить новые проблемы (пусть даже с исправлением всех старых).
Тут подходит пример с факсом - он еще используется, хотя проигрывает современным методам коммуникаций. Но его использование обусловлено наличием старых процессов, которые конкретно сейчас не собираются менять.
Да, всё так, вот только есть несколько (независимых и не очень) системных циклов, которые делают ровно то, что Вы описали. По сути, любая корутина будет выполняться в одном из Dispatcher'ов.
Во-первых, там уже живут люди. Например, климат Сочи лучше климата Питера, но я был рад тому, что в Питере построили дамбу, чтобы нивелировать ущерб от наводнений.
Во-вторых, там может находится что-то полезное, а потому рабочим надо будет где-то жить. А точнее:
Этот город может запустить туризм (а он требует очень много персонала)
Там может быть порт, добыча нефти или фермерские поля (не забываем про ГМО, которое может помочь адаптировать некоторые растения под климат)
Там могут быть электростанции или промышленность, которая требует большого объема энергии (например, сейчас кладут кабель из Туниса в Европу; по задумке солнечную энергию можно добывать в пустынях, а передавать дальше на север).
В-третьих, как я уже сказал, лично мне этот проект нравится тем, что он даст информацию для ученых и инженеров.
Атомную энергетику ведь уже признали зеленой? Ведь признали же?
В мире нет некой "единой комиссии", которая признает что-то зеленым или нет. В ряде стран есть определенные дотации для определенных направлений бизнеса, и их часто связывают с "зелеными", но тут, скорее, будет только корреляция.
Отвечая на вопрос, тут три момента: глобальный, локальный, политический.
Глобальный: основная проблема для текущего климата - это парниковый эффект. Земля получает громадную дозу энергии от Солнца, вот только она всё хуже и хуже рассеивается.
Любой подход, который сможет уменьшить этот самый парниковый эффект, в итоге, приведет к исправлению климата. ГЭС/АЭС позволят сжигать меньше ископаемого топлива, что, в итоге, решит проблему. Ветряки и солнечные панели тоже помогут Земле в целом, но с ними всё хуже (могу расписать детали).
Более того, можно еще компенсировать выбросы путем увеличения объема лесов: по сути, растительность будет "забирать" СО2 из атмосферы.
Локальный: ряд выбросов плохо влияет на людей, а потому переход на условный газ или вынос электростанции подальше из города решит эту проблему. Конечно же, АЭС поможет и тут.
Политический: такие вещи, как АЭС, требуют очень больших инвестиций на начальном этапе, а далее их будут очень долго строить, плюс потом их надо обслуживать и утилизировать отходы. Каждый пункт очень лакомый для коррупции, а то же самое топливо еще и закупать сложно (его продает малое число стран, с которыми тоже придется договариваться). Строительство же газовых электростанций и ветряков намного проще и подконтрольнее, а потому нередко их предпочитают.
Не знаю. Но, для научного эксперимента, так даже лучше. А вдруг получится удачно? В ОАЭ некоторые проекты получились достойными, а некоторые - не очень, но даже неудачные (такие, как искусственные острова) дали новые знания для человечества.
Лично мне эта идея нравится как очень хороший научный эксперимент. По задумке получится озеленить и приспособить к жизни еще один кусочек пустыни, что уже хорошо. А, в идеале, следующая модель запросто будет более дешевой и эффективной.
все текущее айти это буквально Карого-Культ очередного фреймворка и языка с толпой фанатиков
На основе чего у Вас такое утверждение? Разве есть свидетельства того, что большинство разработчиков являются фанатиками некоего единственного фреймворка или языка? И что это за язык такой (начнем с него)?
Почему? Как раз наоборот: сильный коллега сделает команду сильнее, что позволит эффективнее выполнять задачи и тратить меньше времени на споры в стиле "я не знаю gradle, он никогда не будет популярным".
Если речь идет о некой "карьере", то это работает только для крупных компаний (и, желательно, не outsource), а там еще сильнее работает абзац выше, ибо слабые сотрудники уведут команду в бесконечную поддержку продукта и бюрократию, вместо движения вперед.
На самом деле, работа тимлидом несет в себе довольно серьезный карьерный риск, так как:
Опыт накапливается намного медленнее, чем у коллег по команде. Даже если тимлид занимается ревью кода, это и близко не сопоставимо с реальной задачей.
Основная масса управленческой работы заканчивается на уровне "сотрудник хочет в отпуск, можно подписать бумагу и согласиться, или не подписать, и начать искать нового человека, взамен ушедшего, через X недель".
Опыт в общении имеет, как показывает практика, основной смысл только в текущей компании, в текущем отделе, ибо даже другой отдел уже может требовать другого уровня бюрократии и согласований.
В подавляющем числе случаев тимлидов повышают из своих сотрудников, что приводит к тому, что очень сложно перейти на позицию тимлида в другой фирме, ибо ей выгоднее повысить своего сотрудника. Но часто предлагают обман: "ты пока поработаешь разработчиком, а потом, возможно, мы тебе дадим команду", тогда как условный чистый управленец пойдет именно на позицию управленца.
Как показывает практика, есть немало плохих тимлидов (с любовью с микроменеджменту и пр.), и есть немало тех, кто стал управлять на уровне мидла (самая простая проверка - насколько много разных решений человек может предложить для закрытия задачи). Как следствие из этого, можно сделать вывод, что отбор на этих должностях проходит очень плохо после назначения на них. Как следствие из этого, очень легко стать плохим тимлидом, а далее, вместе с первым пунктом, можно вообще получить комбо "слабый сотрудник и очень слабый управленец", ибо обратная связь очень хлипкая.
Тут играет еще момент массовости: 10 запланированных лунных миссий будет стоить дешевле, чем десятикратная стоимость единственной запланированной.
По сути, это обыгрывается в подходах по управлению бизнесом от MBA: есть капитальные затраты (они необходимы вне зависимости от выпуска продукции, например - строительство завода), а есть операционные (например - затраты на исходные материалы для продукции). Если капитальные затраты довольно большие (например, построить инфраструктуру для связи с аппаратом на Луне), то как раз футуристический подход будет более осмысленный.
Или пересчитывайте рубли на цену квадратного метра в районе получасовой доступности от офиса
Это опасная метрика, так как Вы берете, по сути, индекс от индекса, так что идет аккумуляция погрешностей.
Ваша метрика будет колебаться даже от таких вещей, как изменение доли нового элитного жилья в определенных районах (а новостройки дают довольно серьезный вклад в среднюю цену за метр, которую нередко считают по сделкам за определенный период).
Иногда корректнее признать определеную погрешность изначальной метрики, нежели вводить новую, которая может быть менее достоверной.
Судя по этому рейтингу, Cobol находится на одном уровне с Kotlin (который используется едва ли не в большинстве всех Android приложений, который является рекомендованным по-умолчанию для Gradle, и который входит (вместе с Java) в список языков, которые используются в документации Spring.
Собственно, есть подозрение, что этот рейтинг очень плохо отражает реальность...
Вы специально пропустили глагол "читать", чтобы подчеркнуть, что писать write only код очень легко? :)
Подобные вопросы на эрудицию, конечно же, не очень помогают найти именно хорошего синьора, тут спору нет. Вот только я видел кучу раз то, как люди заваливались на очень простых задачах на написание кода (буквально "найдите индесы всех букв 'а' в строке, выбирайте любой язык), хотя резюме претендовало очень крутого специалиста.
А потому, вопросы на live coding очень хороши (если берут не чистого управленца), но вопросы на глубокое знание одной конкретной библиотеки - это очень странно (если только человек не написал, что является экспертом в ней, тогда стоит проверить, как кандидат определяет слово
эксперт).Если в роли предполагается знания языков программирования (ну или определенного), то необходимо показать необходимый уровень, причем каждый следующий включает в себя предыдущий. Условно говоря, джуниор может завалиться на вопросе для мидла, а синьор (и, особенно, тимлид) - нет.
Другими словами, если Вы не пишете код (а потому собеседование будет пройти непросто), то лучше выбирать роли чистого управленца, где будут спрашивать про MBA, попросят показать, как Вы выбираете risk appetite и пр.
Я не до конца этого понимаю.. Вот есть у меня Map в переменной. Могу ли я в цикле проверять "есть ли элемент в Map", если число проверок будет столько же, сколько и размер Map? Для HashMap - однозначно, а вот для TreeMap я свалюсь в NlogN (N проверок по logN), плюс в Java будут еще проблемы с нелокальностью памяти (но это, зачастую, уже мелочи).
Аналогично про List - отличный интерфейс, вот только могу ли я спокойно сохранить его в переменную (так как он неизменный, как и 99% List'ов в программе) или нет? А могу ли я добавлять туда элементы (так как это копия) или же я получу ошибку?
Ответы будут только тогда, когда я получу очень узкий интерфейс, который, по сути, будет полностью описывать реализацию.
Мне всё-таки так не кажется. Функциональный подход (для JVM это будет Scala/Kotlin) дает намного больше пользы. Он автоматически покрывает DDD (по сути, DDD из него и выходит), он сразу применяет
Open-closed Principle(за счет того, что намного проще скрывать не только классы/методы, но и область видимости переменных) и так далее.И это очень сложное утверждение, так как, например, можно придраться, что логгирование действий выходит из зоны ответственности, как и проверка входных переменных, а можно сказать, что это не так. Тут очень тонкая философия, которую, с моей субъективной точки зрения, сложно синхронизовать в команде.
Довольно занятно, как в реальных проектах ломаются все озвученные принципы:
И это приводит к разрастанию очень и очень маленьких классов (буквально по одному методу), а потому становится очень сложно понять, что же происходит.
Не совсем. Если меняются сигнатуры, то это запросто повлечет изменения в куче мест. Более того, тут используется термин "класс родитель", а потому можно предположить, что предлагается делать наследование. Если так, то добавление нового аргумента в конструктор базового класса поменяет вообще все классы наследники.
Это очень опасный подход, кстати, так как декоратору придется реагировать на все-все изменения сигнатур методов, плюс сложно будет понять, правильный ли интерфейс используется или нет.
Если исключить самые-самые простые примеры, это принцип не работает даже в небольших проектах. Несмотря на то, что интерфейс к базе может быть общий, синтаксис запросов будет очень разным (как пример). Несмотря на то, что существует интерфейс List в Java (IList в .Net), в реальной программе всё-таки требуется знать, изменяемый объект или нет, это ArrayList или LinkedList и так далее. Аналогично про интерфейс Map (это может быть и хеш таблица, и дерево).
Возможно, это странный перевод, так как википедия говорит, что:
И, в целом, идея даже правильная, вот только даже List, приведенный в пример выше, уже нарушает этот принцип. Собственно, если честно следовать этой логики, то у каждого интерфейса должен быть строго один метод, иначе можно быстро найти пример, когда код нарушает правило.
Это очень спорное правило, на самом деле. Как раз наоборот - если я использую драйвер к базе, я четко осознаю, как он работает. Если я читаю строки из файла, я именно понимаю, как всё будет происходить. Более того, если мы не делаем библиотеку, то мне намного легче видеть, что конкретно вызывается (с поправкой на unit тесты, где могут быть подмены), вместо того, чтобы иметь еще один проект посередине, чтобы каждый раз просить IDE перейти к реализации. Собственно, я привел примеры выше про List и Map.
Более того, если представить, что нам захочется сменить базу данных, то такая мелочь, как смена типов в программе, будет незаметна даже на фоне созвонов и договоренностей с Dev Ops.
На самом деле, основной совет должен быть "код должен легко поддерживать изменения в рамках ответственности проекта".
Условно говоря, если в проекте постоянно добавляются интеграции с другими сервисами, но всегда есть одна и только одна база данных, то можно смело рассчитывать на неизменность базы, но заодно следует готовиться к новым внешним сервисам.
Заодно правило выше будет толкать к написанию правильных текстов, к более читаемым и строгим типам, к наличию необходимой документации и корректного ревью кода.
Парниковый эффект меняет климат - где-то становится теплее, где-то холоднее. Условное таяние ледников запросто приведет к остановке гольфстрима, так что в Гренландии, Исландии, Норвегии и Швеции будет еще холодее.
Заодно запросто климат может поменяться на более засушливый (в некоторых районах), что создаст проблемы с земледелием. Ну или на более влажный, тогда будет больше рекордных наводнений и пр. Понятно, что, если есть возможность магическим образом перенести города чуть-чуть вбок, то проблем бы с теми же наводнениями не было, но, по факту, придется или строить дорогие дамбы, или сносить уже построенные здания (а города очень часто недалеко от рек, ибо в них очень много плюсов).
Пруфы:
https://ru.wikipedia.org/wiki/Гольфстрим
https://www.nkj.ru/archive/articles/23229/
Это нормально. У меня:
Собственно, только в 2014 у меня получилось написать такую статью, чтобы её одобрило НЛО в песочнице.
Таких библиотек много, но добавим 1-2 часа на интеграцию.
Мне сложно даже сказать, в какой технологии этого нет.
В банках уже используется Java, Kotlin, Python, C++ и еще куча всего, если верить вакансиям. Я не знаю, откуда это дополнительно требование.
Мне сложно поверить, что современный JVM (с зелеными потоками и пр.) будет медленнее, чем Cobol. Разве есть хоть какие-то свидетельства этого?
Это задача на один день для человека, который имеет опыт с другим языком JVM, ну или на 1-4 недели изучения и работы, если человек вообще новичок. Так-то Котлин в вузах изучают, на нем программы пишут уже после первых пары занятий (то есть буквально после потраченных 3-5 часов). Затраты только на поиск специалиста на Cobol будут больше.
Там нет ничего такого. Это язык полный по тьюрингу, уровень типизации у него низкий и так далее. Честная перепись на условный Kotlin (с корректной типизацией и пр.) не будет сколько-нибудь сложной вещью, да и финальное приложение будет более читаемое.
Основная проблема в том, что на Cobol осталось только дремучее легаси, которое переписать стоит больше, чем бюджет отдела на год. Более того, проблемы (если верить слухам) усугубляются тем, что ряд приложений уже одобрены/сертифицированы (пусть даже выдают не всегда корректные данные), а документация утеряна, так что перепись на любой другой язык несет в себе риск получить новые проблемы (пусть даже с исправлением всех старых).
Тут подходит пример с факсом - он еще используется, хотя проигрывает современным методам коммуникаций. Но его использование обусловлено наличием старых процессов, которые конкретно сейчас не собираются менять.
Да, всё так, вот только есть несколько (независимых и не очень) системных циклов, которые делают ровно то, что Вы описали. По сути, любая корутина будет выполняться в одном из Dispatcher'ов.
Во-первых, там уже живут люди. Например, климат Сочи лучше климата Питера, но я был рад тому, что в Питере построили дамбу, чтобы нивелировать ущерб от наводнений.
Во-вторых, там может находится что-то полезное, а потому рабочим надо будет где-то жить. А точнее:
Этот город может запустить туризм (а он требует очень много персонала)
Там может быть порт, добыча нефти или фермерские поля (не забываем про ГМО, которое может помочь адаптировать некоторые растения под климат)
Там могут быть электростанции или промышленность, которая требует большого объема энергии (например, сейчас кладут кабель из Туниса в Европу; по задумке солнечную энергию можно добывать в пустынях, а передавать дальше на север).
В-третьих, как я уже сказал, лично мне этот проект нравится тем, что он даст информацию для ученых и инженеров.
В мире нет некой "единой комиссии", которая признает что-то зеленым или нет. В ряде стран есть определенные дотации для определенных направлений бизнеса, и их часто связывают с "зелеными", но тут, скорее, будет только корреляция.
Отвечая на вопрос, тут три момента: глобальный, локальный, политический.
Глобальный: основная проблема для текущего климата - это парниковый эффект. Земля получает громадную дозу энергии от Солнца, вот только она всё хуже и хуже рассеивается.
Любой подход, который сможет уменьшить этот самый парниковый эффект, в итоге, приведет к исправлению климата. ГЭС/АЭС позволят сжигать меньше ископаемого топлива, что, в итоге, решит проблему. Ветряки и солнечные панели тоже помогут Земле в целом, но с ними всё хуже (могу расписать детали).
Более того, можно еще компенсировать выбросы путем увеличения объема лесов: по сути, растительность будет "забирать" СО2 из атмосферы.
Локальный: ряд выбросов плохо влияет на людей, а потому переход на условный газ или вынос электростанции подальше из города решит эту проблему. Конечно же, АЭС поможет и тут.
Политический: такие вещи, как АЭС, требуют очень больших инвестиций на начальном этапе, а далее их будут очень долго строить, плюс потом их надо обслуживать и утилизировать отходы. Каждый пункт очень лакомый для коррупции, а то же самое топливо еще и закупать сложно (его продает малое число стран, с которыми тоже придется договариваться). Строительство же газовых электростанций и ветряков намного проще и подконтрольнее, а потому нередко их предпочитают.
Не знаю. Но, для научного эксперимента, так даже лучше. А вдруг получится удачно? В ОАЭ некоторые проекты получились достойными, а некоторые - не очень, но даже неудачные (такие, как искусственные острова) дали новые знания для человечества.
Лично мне эта идея нравится как очень хороший научный эксперимент. По задумке получится озеленить и приспособить к жизни еще один кусочек пустыни, что уже хорошо. А, в идеале, следующая модель запросто будет более дешевой и эффективной.
На основе чего у Вас такое утверждение? Разве есть свидетельства того, что большинство разработчиков являются фанатиками некоего единственного фреймворка или языка? И что это за язык такой (начнем с него)?
Почему? Как раз наоборот: сильный коллега сделает команду сильнее, что позволит эффективнее выполнять задачи и тратить меньше времени на споры в стиле "я не знаю gradle, он никогда не будет популярным".
Если речь идет о некой "карьере", то это работает только для крупных компаний (и, желательно, не outsource), а там еще сильнее работает абзац выше, ибо слабые сотрудники уведут команду в бесконечную поддержку продукта и бюрократию, вместо движения вперед.
На самом деле, работа тимлидом несет в себе довольно серьезный карьерный риск, так как:
Опыт накапливается намного медленнее, чем у коллег по команде. Даже если тимлид занимается ревью кода, это и близко не сопоставимо с реальной задачей.
Основная масса управленческой работы заканчивается на уровне "сотрудник хочет в отпуск, можно подписать бумагу и согласиться, или не подписать, и начать искать нового человека, взамен ушедшего, через X недель".
Опыт в общении имеет, как показывает практика, основной смысл только в текущей компании, в текущем отделе, ибо даже другой отдел уже может требовать другого уровня бюрократии и согласований.
В подавляющем числе случаев тимлидов повышают из своих сотрудников, что приводит к тому, что очень сложно перейти на позицию тимлида в другой фирме, ибо ей выгоднее повысить своего сотрудника. Но часто предлагают обман: "ты пока поработаешь разработчиком, а потом, возможно, мы тебе дадим команду", тогда как условный чистый управленец пойдет именно на позицию управленца.
Как показывает практика, есть немало плохих тимлидов (с любовью с микроменеджменту и пр.), и есть немало тех, кто стал управлять на уровне мидла (самая простая проверка - насколько много разных решений человек может предложить для закрытия задачи). Как следствие из этого, можно сделать вывод, что отбор на этих должностях проходит очень плохо после назначения на них. Как следствие из этого, очень легко стать плохим тимлидом, а далее, вместе с первым пунктом, можно вообще получить комбо "слабый сотрудник и очень слабый управленец", ибо обратная связь очень хлипкая.
Тут играет еще момент массовости: 10 запланированных лунных миссий будет стоить дешевле, чем десятикратная стоимость единственной запланированной.
По сути, это обыгрывается в подходах по управлению бизнесом от MBA: есть капитальные затраты (они необходимы вне зависимости от выпуска продукции, например - строительство завода), а есть операционные (например - затраты на исходные материалы для продукции). Если капитальные затраты довольно большие (например, построить инфраструктуру для связи с аппаратом на Луне), то как раз футуристический подход будет более осмысленный.
Это опасная метрика, так как Вы берете, по сути, индекс от индекса, так что идет аккумуляция погрешностей.
Ваша метрика будет колебаться даже от таких вещей, как изменение доли нового элитного жилья в определенных районах (а новостройки дают довольно серьезный вклад в среднюю цену за метр, которую нередко считают по сделкам за определенный период).
Иногда корректнее признать определеную погрешность изначальной метрики, нежели вводить новую, которая может быть менее достоверной.