и тем не менее, автомобилей на джойстиках как-то не встречал.
Очевидно, пока автомобили не летают, им ни к чему стик отклоняющийся в трёх измерениях. во всех случаях — и на самолётах, и на авто, органы управления выведены опытным путём. Как, и, например, максимальное отклонение руля для поворота (нет никаких больше — лучше). Разные области применения, разные среды. На формуле больше скорости, больше сцепление, меньше резких поворотов — больше микродвижений. На ДОП куча мест где нужно развернуться полностью на небольших участках при минимальной скорости — соответственно другие требования к рулю. Самолёты в данном случае ближе к формуле, всё-таки (это не про переключение скоростей лепестками, а про микродвижения в принципе).
Почему, например, на формуле руль, а не стик в таком случае — скорее всего обусловлено в первую очередь стандартами (спорт — там их бездна), во вторую необходимостью качественного прямого обратного отклика (опять же спорт).
Потому что переход на это сделать крайне сложно. Взять проект который уже живёт два года — да никто не будет там так глобально ничего менять. А заменить конкретно взятый инструмент другим — возможно.
Одна экосистема хорошо. Но заменить текущий стек совершенно новым — почти нереально для больших команд или очень дорого для бизнеса. Потому я и говорю про плавный переход. Время на адаптацию, чтоли.
бегать из одной системы в другую
Это вполне привычно и не так сложно при хорошей интеграции. Например G-suite с календарём — а теперь взять и мигрировать на какой-то новый календарь, который непонятно как (никак скорее всего) интегрируется с тем же G-suite. Или слэк с несколькими аккаунтами для разных проектов, где пользователи легко перетекают из одной в другую тесно интегрируясь с другими компаниями — а теперь предлагается какой-то свой чат, куда нужно будет или приглашать другие команды каким-то образом, или просто пользоваться несколькими чатами вместо одного (у нас 10 стандартов — нужно сделать один универсальный. Теперь у нас 11 стандартов).
Мне кажется, этот комментарий на 100% можно развернуть в обратную сторону.
Раньше код "ехал" — выполнял что должен выполнять в 99.9999999% случаев и если где-то проскакивало 1000КБ — то было это при выводе на экран и в общем никого не колыхало (ничего не могло сломать).
Теперь это не только "ехать", но ещё и "шашечки", которые, как-бы, и не очень-то были нужны (для "ехать").
А вот сделали бы конструктор — каждая команда нашла бы что-то для себя. А так будут взвешивать ± перед тем как полностью переходить и не факт что в вашу пользу. Как по мне, то это сразу потеря клиентов.
Запаковывать всё в одну систему нужно уже потом, когда есть активные пользователи и им можно предложить внутренний аналог удобнее чем внешний, который они уже используют, но находясь в вашей системе. И не всё сразу, разумеется.
Ну не так, но говорят "ну вы же понимаете, у нас стартап, потому переработки неизбежны и работа на выходных тоже может быть". А может быть это значит, что ты обязан быть доступен на выходных, на всякий случай.
а вот задний лежак… если кто влетит на скорости 100+
Там достаточно места для скольжения кресла вперёд, кмк. Это разве что сверху что-то упадёт.
обозвали детские сидушки местами
Вообще в этом есть здравый смысл. Когда в обычной машине установлено детское кресло (3-4 года, потом бустер), то оно занимает где-то 1.2 места. И при этом ставится не по центру, а на нормальное, взрослое место. Таким образом, обзывать машину 4-х местной тоже как-то неправильно, когда там 2.5 места для пассажиров и одно детское. Посмотрите сколько вокруг машин с детскими креслами, по прикидкам с потолка каждое пятое будет.
Да, снять можно, но это редкость по очень простой причине — некуда ребёнка оставить (или незачем), потому он всегда ездит с тобой (если семьёй ехать).
Для семьи с тремя детьми (я подозреваю, в Китае это не редкость), детское место скорее всего будет занято почти всегда.
Запускайте остальные приложения, печатая в командной строке
Слегка противоречит переходу на свайп. Либо мы быстрее запускаем приложение, и быстрее из него выходим, либо просто быстро свайпом набираем название и ничего не меняется.
Не заряжайте девайсы в спальне
Сомнительно. На том же iOS (большая часть советов про него) есть режим сна (есть и на Андроиде, но на iOS, кмк, радикальнее) — в ночное время при включении экрана он затемнён, и на нём отсутствуют уведомления, только часы. На обоих платформах при этом отключены оповещения и дозвониться можно только со второго раза (по умолчанию).
Звоните или отправляйте голосовые сообщения вместо текстовых
В аду есть отдельный котёл для тех, кто использует голосовые сообщения на смартфоне. Выше уже несколько раз написали об этом.
Набор свайпом требует на 50% меньше времени
Кроме того, есть мнение (+ к голосовым сообщениям), что чем проще написать (проговорить) сообщение, тем больше бессмысленных сообщений будет в переписке. Соответственно, чем сложнее набирать — тем больше сообщений будет "по делу" и меньше о погоде.
InboxWhenReady (Gmail)
Противоречит "уведомлениям от людей" и вообще малополезно. Лучше настроить категории и фильтрацию, чтоб в оповещения попадали только сообщения от людей и важные, а рассылки складывались бы в отдельную категорию без оповещений.
Flux (Mac, Windows)
При чём оно вообще здесь?
Moment (iOS)
Уже устарело, в IOS есть нативный функционал по отслеживанию времени в приложениях.
Быстрые команды в сообщениях: используйте быстрые реакции
Неприменимо ко всем приложениям.
Daily time in app for happy and unhappy users
Чёт вообще без аннотации непонятно о чём (и не хочется тратить своё время чтоб разобраться) график.
Мне кажется это может выглядеть как-то так (разумеется, это сильно-силньо набросок):
Взломщик обязан связаться с владельцем для уведомления в течении часа.
Взломщик должен поставить в известность стороннюю службу (хз какую) о факте взлома и о том, что владелец был уведомлён.
Если это не несёт ущерб, взломщик должен сменить все пароли и передать новые пароли владельцу (если не смог связаться с ним в оговоренные сроки).
Если несёт, взломщик может самостоятельно вылечить заразу (если нет рисков ущерба, опять же).
Таким образом, если всё описанное выполнено и зафиксировано (то самое обращение в стороннюю службу), взломщик может претендовать на оплату, а так же на +1 white-hat взлом в системе учёта оных.
Соотвественно, если что-то было не выполнено, или выполнено не по протоколу (знал об ущербе, но всё-равно сменил пароли), то это уже злоумышленные действия со всеми вытекающими.
Тем не менее, пока это не будет закреплено на законодательном уровне — лучше так не делать, посколько пока что закреплено обратное. Взломал — должен быть наказан.
При посадке в случае чего немного легче увеличить тягу, кроме того, если полоса позволяет по длине — проблем никаких нет. При взлёте и так на максимуме, увеличивать некуда, шмякаться обратно вообще не вариант вне зависимости от длины полосы.
Очевидно, пока автомобили не летают, им ни к чему стик отклоняющийся в трёх измерениях. во всех случаях — и на самолётах, и на авто, органы управления выведены опытным путём. Как, и, например, максимальное отклонение руля для поворота (нет никаких больше — лучше). Разные области применения, разные среды. На формуле больше скорости, больше сцепление, меньше резких поворотов — больше микродвижений. На ДОП куча мест где нужно развернуться полностью на небольших участках при минимальной скорости — соответственно другие требования к рулю. Самолёты в данном случае ближе к формуле, всё-таки (это не про переключение скоростей лепестками, а про микродвижения в принципе).
Почему, например, на формуле руль, а не стик в таком случае — скорее всего обусловлено в первую очередь стандартами (спорт — там их бездна), во вторую необходимостью качественного прямого обратного отклика (опять же спорт).
Авторизацию починила давно, единственное отличие в том, что в UI не исправили
PasswordнаAPI Token(можно по комментариям отследить).EDIT: хотя видимо всё ещё не работает для JIRA Server
Отсутствие интеграции с тем, что нужно? Хорошо, если она будет, конечно.
Потому что переход на это сделать крайне сложно. Взять проект который уже живёт два года — да никто не будет там так глобально ничего менять. А заменить конкретно взятый инструмент другим — возможно.
Одна экосистема хорошо. Но заменить текущий стек совершенно новым — почти нереально для больших команд или очень дорого для бизнеса. Потому я и говорю про плавный переход. Время на адаптацию, чтоли.
Это вполне привычно и не так сложно при хорошей интеграции. Например G-suite с календарём — а теперь взять и мигрировать на какой-то новый календарь, который непонятно как (никак скорее всего) интегрируется с тем же G-suite. Или слэк с несколькими аккаунтами для разных проектов, где пользователи легко перетекают из одной в другую тесно интегрируясь с другими компаниями — а теперь предлагается какой-то свой чат, куда нужно будет или приглашать другие команды каким-то образом, или просто пользоваться несколькими чатами вместо одного (у нас 10 стандартов — нужно сделать один универсальный. Теперь у нас 11 стандартов).
У вас между этими строками потерялась пара абзацев на тему почему не Lua.
Мне кажется, этот комментарий на 100% можно развернуть в обратную сторону.
Раньше код "ехал" — выполнял что должен выполнять в 99.9999999% случаев и если где-то проскакивало 1000КБ — то было это при выводе на экран и в общем никого не колыхало (ничего не могло сломать).
Теперь это не только "ехать", но ещё и "шашечки", которые, как-бы, и не очень-то были нужны (для "ехать").
А вот сделали бы конструктор — каждая команда нашла бы что-то для себя. А так будут взвешивать ± перед тем как полностью переходить и не факт что в вашу пользу. Как по мне, то это сразу потеря клиентов.
Запаковывать всё в одну систему нужно уже потом, когда есть активные пользователи и им можно предложить внутренний аналог удобнее чем внешний, который они уже используют, но находясь в вашей системе. И не всё сразу, разумеется.
Но это достаточно указать только в тех столбцах, которые должны быть выровнены. Ну и одним
monospacedвыбор моноширинных шрифтов не ограничен.Речь про наоборот. Это целый доклад на тему "а давайте в местах где есть выравнивание использовать моноширинный шрифт".
Ну не так, но говорят "ну вы же понимаете, у нас стартап, потому переработки неизбежны и работа на выходных тоже может быть". А может быть это значит, что ты обязан быть доступен на выходных, на всякий случай.
Но вы ведь можете получить доступ умышленно не имея ни мотива, ни выгоды. Как тогда?
Для этого есть более точный перевод "тебе следует/стОит" (работает в обе стороны). Всё-таки "должен" — это про другое.
Там достаточно места для скольжения кресла вперёд, кмк. Это разве что сверху что-то упадёт.
Вообще в этом есть здравый смысл. Когда в обычной машине установлено детское кресло (3-4 года, потом бустер), то оно занимает где-то 1.2 места. И при этом ставится не по центру, а на нормальное, взрослое место. Таким образом, обзывать машину 4-х местной тоже как-то неправильно, когда там 2.5 места для пассажиров и одно детское. Посмотрите сколько вокруг машин с детскими креслами, по прикидкам с потолка каждое пятое будет.
Да, снять можно, но это редкость по очень простой причине — некуда ребёнка оставить (или незачем), потому он всегда ездит с тобой (если семьёй ехать).
Для семьи с тремя детьми (я подозреваю, в Китае это не редкость), детское место скорее всего будет занято почти всегда.
Слегка противоречит переходу на свайп. Либо мы быстрее запускаем приложение, и быстрее из него выходим, либо просто быстро свайпом набираем название и ничего не меняется.
Сомнительно. На том же iOS (большая часть советов про него) есть режим сна (есть и на Андроиде, но на iOS, кмк, радикальнее) — в ночное время при включении экрана он затемнён, и на нём отсутствуют уведомления, только часы. На обоих платформах при этом отключены оповещения и дозвониться можно только со второго раза (по умолчанию).
В аду есть отдельный котёл для тех, кто использует голосовые сообщения на смартфоне. Выше уже несколько раз написали об этом.
Кроме того, есть мнение (+ к голосовым сообщениям), что чем проще написать (проговорить) сообщение, тем больше бессмысленных сообщений будет в переписке. Соответственно, чем сложнее набирать — тем больше сообщений будет "по делу" и меньше о погоде.
Противоречит "уведомлениям от людей" и вообще малополезно. Лучше настроить категории и фильтрацию, чтоб в оповещения попадали только сообщения от людей и важные, а рассылки складывались бы в отдельную категорию без оповещений.
При чём оно вообще здесь?
Уже устарело, в IOS есть нативный функционал по отслеживанию времени в приложениях.
Неприменимо ко всем приложениям.
Чёт вообще без аннотации непонятно о чём (и не хочется тратить своё время чтоб разобраться) график.
Мне кажется это может выглядеть как-то так (разумеется, это сильно-силньо набросок):
Соотвественно, если что-то было не выполнено, или выполнено не по протоколу (знал об ущербе, но всё-равно сменил пароли), то это уже злоумышленные действия со всеми вытекающими.
Но ведь доказательств не мотива, а доказательств преступления и ущерба, разве нет?
Тем не менее, пока это не будет закреплено на законодательном уровне — лучше так не делать, посколько пока что закреплено обратное. Взломал — должен быть наказан.
При посадке в случае чего немного легче увеличить тягу, кроме того, если полоса позволяет по длине — проблем никаких нет. При взлёте и так на максимуме, увеличивать некуда, шмякаться обратно вообще не вариант вне зависимости от длины полосы.
Это про фриланс, а не про удалёнку. На удалёнке у меня сейчас проект который длится уже два года. Стабильность и планирование — хоть отбавляй.
Ну, скажем, пешеходу одинаково будет, даже с современными сминаемыми кузовами. А вот другим ТС да — там всмятку со всеми вытекающими для пассажиров.
Вот да, прям и видится как при столкновении эта махина взмывает в воздух целиком не сминаясь.