Корень проблемы в том, что В-737 — самолёт традиционной схемы управления: тянешь штурвал — усилия посредством тросов передаются на золотник гидравлического привода и пропорционально отклонению штурвала отклоняется рулевая поверхность.
У Су-27 и Эйрбас А320 все происходит по-другому: отклонение ручки управления передается в компьютер, который исходя из условий полета сам принимает решение, на какой угол отклонить руль высоты, к примеру.
Почему это важно? Потому что во втором случае можно создать безопасный статически неустойчивый самолёт, а в первом — нет. Вот инженерам Боинга и пришлось городить костыли, чтобы обеспечить устойчивость неустойчивого на ряде режимах самолёта.
Итог: костыли проявились во всей красе.
В работе на отечественный рынок нет ничего плохого.
Ничего плохого нет, однако зачастую зарплаты при работе на зарубежный рынок — выше. А при работе на зарубежный рынок уровня В1 — совершенно недостаточно. Рассказать статус своих задач вы сможете, а вот обсудить с архитектором проекта (он же не обязательно будет русскоговорящий) какие-либо нюансы или отстоять свою точку зрения — уже нет.
А самое главное — вы очень с трудом будет понимать речь нэйтивов и это будет доставлять очень большой дискомфорт.
Ух ты, я был уверен, что компиляция с промежуточным компилированием в ассемблер осталась далеко в прошлом.
А что мешает компилировать сразу в исполняемый код? И, как я понимаю, другие языки такой подход не используют, или я не прав?
>> После презентации Cybertruck акции Tesla упали на 9%.
Чтобы не было неверных трактовок, стоит добавить, что с начала октября они сначала выросли более чем в полтора раза (57%), а затем скорректировались вниз на 9%.
Схожую картину можно наблюдать после демонстрации новых продуктов компанией Эппл: ее акции всегда падают после демонстрации. Причиной тут видится несколько перегретые ожидания от новых продуктов.
Да все проще: каждому производителю будет выслан архив apk-шек, которые они должны будут запихнуть в прошивку для России. Приложения будут системными, а значит, — без рута неудаляемыми.
В этом никакого ноу-хау нет, и так в прошивках можно обнаружить предустановленные сторонние приложения: Скайп там, Фейсбук, или игры.
PS. Но как это возможно будет для айфонов — не знаю, не имею такого опыта.
Потратил не очень много, думаю, часов восемь на первый запуск, а дальше какие-то минимальные правки уже в процессе эксплуатации.
Про YouTrack я не знал, если честно. Но, дело не только в том, умеет ли из коробки или нет. Jira тоже все это умеет из коробки, но она настолько монстроузная, что ее использование для небольших проектов совершенно не оправдано.
А чем вас интеграция не устраивает? В Jire ставите линку на страницу в Confluence, а в статье (при желании) — линку на задачу в Jira. При этом линки схлопываются до айдишника задачи, сразу виден ее статус и тд. Сам Confluence очень удобен для ведения документации, этакая иерархическая вики.
Насчет «Sub-issues should be able to contain their own sub-issues» — я посмотрел внимательно на ваш скриншот, действительно, если все нюасны проекта раскидывать по иерархии, то трех уровней которые предоставляет Джира, вам будет явно недостаточно. Но можно часть сущеностей реализовать через теги или компоненты. Возможно, это будет даже удобнее в ряде случаев.
Безусловно, большой проект требует серьезных инструментов.
А почему вы не пользуетесь классической связкой Jira + Confluence? В Jira — иерархическое дерево задач, а документация в — в Confluence. Они удобно друг с другом интегрируются, в Confluence видны статусы задач из Jira и тд.
Как раз в этом проекте у меня тоже была геймдизайнерская таблица для расчета баланса. Сначала делал ее в гугл-таблицах, но очень быстро она стала умирать по производительности, ровно так, как вы описываете. В результате перенес в Эксель — тот тянул нормально, но у меня, конечно, меньше 100 листов было.
В общем, это все к выбору оптимального инструмента под конкретную задачу.
Если совсем кратко, то потому, что меня в большей степени волнует, когда задача будет выполнена, а не сколько на нее времени было потрачено.
Если более развернуто, то тут есть интересный психологический момент, благодаря которому такой способ учёта более эффективен, чем учет потраченных часов.
Давайте представим, что мы организовали учёт времени потраченных часов. У нас есть задача, оцененная в 40 часов и разработчик каждый день на нее списывает по 8 часов. И вот на утро пятого дня вы видите, что на задачу было потрачено 32 часа. Означает ли это, что к вечеру он закроет эту задачу? Разумеется, нет. Он может списать на нее еще 8 часов, и еще 8 часов, а задача так и не будет выполнена (допустим, возникли какие-либо сложности).
Более того, если мы в середине этой задчи подойдем и спросим разработчика о ходе работ, то скорее всего мы услышим, что "все идет по плану, все под контролем", а проблема с задержкой сроков вылезет лишь в день сдачи задачи.
Совсем другое дело, когда мы просим ввести количество оставшихся часов. Во1, разработчику приходится задуматься о своем прогрессе и оценить оставшуюся трудоемкость, во2, ввод оставшихся часов это что-то вроде обещания, данного самому себе, что также стимулирует закончить работу в срок.
Но, кстати говоря, этот подход не является чем-то революционным: его поддерживают и Jira, и DevOs и даже MS Project Server. Все это можно настроить в свойствах проекта.
Корень проблемы в том, что В-737 — самолёт традиционной схемы управления: тянешь штурвал — усилия посредством тросов передаются на золотник гидравлического привода и пропорционально отклонению штурвала отклоняется рулевая поверхность.
У Су-27 и Эйрбас А320 все происходит по-другому: отклонение ручки управления передается в компьютер, который исходя из условий полета сам принимает решение, на какой угол отклонить руль высоты, к примеру.
Почему это важно? Потому что во втором случае можно создать безопасный статически неустойчивый самолёт, а в первом — нет. Вот инженерам Боинга и пришлось городить костыли, чтобы обеспечить устойчивость неустойчивого на ряде режимах самолёта.
Итог: костыли проявились во всей красе.
Ничего плохого нет, однако зачастую зарплаты при работе на зарубежный рынок — выше. А при работе на зарубежный рынок уровня В1 — совершенно недостаточно. Рассказать статус своих задач вы сможете, а вот обсудить с архитектором проекта (он же не обязательно будет русскоговорящий) какие-либо нюансы или отстоять свою точку зрения — уже нет.
А самое главное — вы очень с трудом будет понимать речь нэйтивов и это будет доставлять очень большой дискомфорт.
Ух ты, я был уверен, что компиляция с промежуточным компилированием в ассемблер осталась далеко в прошлом.
А что мешает компилировать сразу в исполняемый код? И, как я понимаю, другие языки такой подход не используют, или я не прав?
Чтобы не было неверных трактовок, стоит добавить, что с начала октября они сначала выросли более чем в полтора раза (57%), а затем скорректировались вниз на 9%.
Схожую картину можно наблюдать после демонстрации новых продуктов компанией Эппл: ее акции всегда падают после демонстрации. Причиной тут видится несколько перегретые ожидания от новых продуктов.
Да все проще: каждому производителю будет выслан архив apk-шек, которые они должны будут запихнуть в прошивку для России. Приложения будут системными, а значит, — без рута неудаляемыми.
В этом никакого ноу-хау нет, и так в прошивках можно обнаружить предустановленные сторонние приложения: Скайп там, Фейсбук, или игры.
PS. Но как это возможно будет для айфонов — не знаю, не имею такого опыта.
А каким образом можно собирать HTTPS-трафик? Он разве не шифруется end-to-end?
Да, вы совершенно правы. Это условное форматирование.
Потратил не очень много, думаю, часов восемь на первый запуск, а дальше какие-то минимальные правки уже в процессе эксплуатации.
Про YouTrack я не знал, если честно. Но, дело не только в том, умеет ли из коробки или нет. Jira тоже все это умеет из коробки, но она настолько монстроузная, что ее использование для небольших проектов совершенно не оправдано.
Насчет «Sub-issues should be able to contain their own sub-issues» — я посмотрел внимательно на ваш скриншот, действительно, если все нюасны проекта раскидывать по иерархии, то трех уровней которые предоставляет Джира, вам будет явно недостаточно. Но можно часть сущеностей реализовать через теги или компоненты. Возможно, это будет даже удобнее в ряде случаев.
А почему вы не пользуетесь классической связкой Jira + Confluence? В Jira — иерархическое дерево задач, а документация в — в Confluence. Они удобно друг с другом интегрируются, в Confluence видны статусы задач из Jira и тд.
В общем, это все к выбору оптимального инструмента под конкретную задачу.
Если совсем кратко, то потому, что меня в большей степени волнует, когда задача будет выполнена, а не сколько на нее времени было потрачено.
Если более развернуто, то тут есть интересный психологический момент, благодаря которому такой способ учёта более эффективен, чем учет потраченных часов.
Давайте представим, что мы организовали учёт времени потраченных часов. У нас есть задача, оцененная в 40 часов и разработчик каждый день на нее списывает по 8 часов. И вот на утро пятого дня вы видите, что на задачу было потрачено 32 часа. Означает ли это, что к вечеру он закроет эту задачу? Разумеется, нет. Он может списать на нее еще 8 часов, и еще 8 часов, а задача так и не будет выполнена (допустим, возникли какие-либо сложности).
Более того, если мы в середине этой задчи подойдем и спросим разработчика о ходе работ, то скорее всего мы услышим, что "все идет по плану, все под контролем", а проблема с задержкой сроков вылезет лишь в день сдачи задачи.
Совсем другое дело, когда мы просим ввести количество оставшихся часов. Во1, разработчику приходится задуматься о своем прогрессе и оценить оставшуюся трудоемкость, во2, ввод оставшихся часов это что-то вроде обещания, данного самому себе, что также стимулирует закончить работу в срок.
Но, кстати говоря, этот подход не является чем-то революционным: его поддерживают и Jira, и DevOs и даже MS Project Server. Все это можно настроить в свойствах проекта.