Тут видите как получилось. Пока Boeing вату катал, Airbus выкатил A320 Neo. Улучшения топливной эффективности добились вполне логичным способом - увеличением размера двигателя. Но это ладно, главное было то, что на A320 Neo не надо было перучивать пилотов, совсем.
И "эффективные" менеджеры поставили перед инженерами такую же задачу, причем сделать надо было еще вчера, потому что Neo уже собирает заказы.
Понятно, что MCAS - костыль, у Boeing в обычном 737 двигатель сплющен, а тут его еще увеличивать пришлось.
И вот тут пазл, к сожалению, складывается.
Вместо здравой и верной оценки, что большой двигатель на текущий планер нормально не встает был придуман костыль (MCAS). Либо оценка не была дана (в чем я сомневаюсь), либо менеджмент ее проигнорировал (в это мне верится больше).
О MCAS умалчивают, потому что иначе это обязательная переподготовка пилотов, а надо быть как конкурент, не хуже! (Но на бумаге, а не на деле).
И поскольку сделать надо было еще вчера на процедуры разработки и тестирования... ну вы понимаете.
Boeing в принципе более архаичный и древний на фоне Airbus с его fly-by-wire, так что для них такое нововведение оказалось слишком серьезным.
Эффективные менеджеры во всей их красе. За 7 лет работы в IT сфере понял, что они являются ничем иным, как раковой опухолью индустрии. К огромному сожалению, эти бездари добрались и до авиации.
Я не задавался этим вопросом, так что при всем желании не могу Вам на него ответить. Но, множество IT компаний сейчас предлагают релокацию в свои офисы за пределами РФ. Я думаю, это самый простой способ, потому что множество проблем уже решили за вас. На истину в последней инстанции, само собой, не претендую, и могу быть неправ.
Знаю, поскольку столкнулся с этим в Узбекистане, там он задушен намертво. Хоть и нужен был по работе, а не с целью обхода чего-то. Но в реалиях "сегодня, здесь и сейчас" оно работает. А там будем решать проблемы по мере их возникновения.
Заметил на Мегафоне еще месяц назад. На какое-то время помогла смена порта с дефолтного для OpenVPN на рандомный. Потом легло и оно. В итоге переехал на WireGuard, поднимается едва-ли сложнее, пока работает.
К анти-привовчникам себя не отношу, сам переболел чуть больше месяца назад, обоняние почти не задело, а вот слух сильно проседал дня на 4, в общем и целом перенёс достаточно легко, но знаю людей, которым повезло сильно меньше, увы. Что сказать хочу, спасибо Вам за статью, как минимум за огромные труды, которые были положены в исследование информации для её написания. Просто спасибо.
А, пардон, я неправильно трактовал ваше сообщение, я думал у вас только мышка не кликается, а клавиатура работает, тогда да, такое себе. Кстати, всё же, переход в другое tty тоже не работает? (Ctrl+Alt+F 1 2 3...)?
Для показа Snackbar'a в примере со вторым приложением я тоже использовал middleware. Он следил за единственным интересующим его событием и показывал сообщения, когда что-то прилетало. Я примерно понимаю что Вас смущает в случае с событием DataUpdated, то, что оно пролетит через все Middleware и другие Reducer'ы, потенциально давая возможность прострелить колено, но, в этом весь Redux, это фундаментальный его механизм, сложно будет сделать иначе не нарушив изначальную идею.
Зависит от ситуации. По принципу вынести что-то в общий commons модуль, а остальное в другие — нормально. Если речь про feature модули, тут, к сожалению, подсказать не могу, ввиду отсутствия опыта в реализации подобного подхода.
Да, последовательность действительно имеет значение в данном случае и я бы даже сказал, что надо быть внимательным, но, это редко создаёт проблему, если правильно к этому подойти. Как правило у Вас будет мало случаев, когда несколько разных Middleware следят за одним и тем же событием и пытаются его заменить на что-то другое. Шанс выстрелить себе в ногу, конечно, всегда есть, но больших проблем я особо не заметил, да и логика эта хорошо покрывается тестами, что даёт большую уверенность в отсутствии регрессий. Отличный вопрос, кстати.
Я приводил пример подхода чуть ниже в ответ на другой комментарий. Вкратце — зависит от того, как Вы построите состояние. Моё мнение в чем: При другом подходе данных меньше у Вас не станет, они просто будут разбросаны по всему приложению, часть во фрагменте, часть в интеракторе, часть ещё где-то и т.д.
В случае с Redux они просто лежат в одном месте, а всё остальное эти данные только использует, но не хранит.
В более сложной конструкции части ApplicationState описываются иначе.
Например как-нибудь вот так:
data class ApplicationState {
... some other data here
val bottomSheetState: BottomSheetState,
val currentScreenState: CurrentScreenState
}
При этом BottomSheetState и CurrentScreenState могут являться sealed классами с явно ограниченным количеством возможных вариантов
BottomSheetState.kt
sealed class BottomSheetState {
data class SimpleMessageBottomSheetState(...) : BottomSheetState()
data class MessageWithButtonBottomSheetState(...) : BottomSheetState()
}
CurrentScreenState.kt
sealed class CurrentScreenState {
data class Home(...) : CurrentScreenState()
data class Profile(...) : CurrentScreenState()
data class Settings(...) : CurrentScreenState()
}
Т.е. получается что у нас есть стейт какого-то BottomSheet'a или конкретного экрана и в момент времени активным может быть только один из. Но в тоже время в ApplicationState рядом могут лежать и другие данные, которые каждый может дергать на любом экране. Мне кажется, что в целом это баланс, между работоспособностью и достаточно простым на восприятие состоянием. Создатели Redux на JS в одной из частей документации даже описывают подход, как лучше структурировать состояние. Вкратце — более плоское состояние — лучше, сильно много вложенностей усложняют работу с такой конструкцтей.
Если под дроблением вы имели ввиду что-то другое и я не до конца ответил на Ваш вопрос — дайте пожалуйста знать, подискутируем.
Сложно дать однозначный ответ, потому что эта логика очень зависит от конкретной ситуации. Т.е. если Вам на событие А нужно что-то загрузить из сети и потом отправить событие В, то в middleware можно просто запустить запрос поймав событие А и при этом вернуть событие А дальше, таким образом, оно дойдет до reducer'a. А когда запрос выполнится — сделать dispatch события B. Либо же можно делать dispatch из самого middleware, но это нужно делать осторожно, потому что редукс синхронный сам по себе. Вообще, очень хороший вопрос и это своего рода краеугольный камень, с событиями надо быть осторожным, особенно когда речь идёт о замене одного на другое.
Зависит от того, что именно Вы хотите получить. Вряд-ли Вам нужно ограничивать время жизни всего State, скорее какой-нибудь его части, так ведь? Приведу пример, если я правильно понял вопрос. В ApplicationState можно положить BottomSheetState, который будет отвечать за отображение вот такого UI элемента. У него могут быть различные вариации для отображения различных состояний, но, если у Вас в настоящий момент времени скрыт BottomSheet — просто ставите state = null и всё, на стороне UI соответственно подписка на эту часть состояния и отображение / скрытие UI элемента в зависимости от значения.
There's an easier way, man: just buy a MacBook or install Linux :)
Speaking seriously, I recently installed a licensed Windows 10 from an official USB drive and immediately after installing I'm trying to update my system but it constantly fails to install update. It was build 19** and I didn't have a chance to upgrade to the latest 20H2 version. I've spent 3 hours, 3, damn, hours, trying to install this update to clean and official installation of the Windows 10 and ended up using the Update Assistant. It seems to me that Windows is fundamentally broken, unfortunately. It's not acceptable for the system to behave in this way.
It's just my opinion, I'm not a fan of a particular OS, because the main thing that system should do — is to solve my problems, but when we talking about Windows I have a strong feeling that I'm constantly fight with the system instead of using it.
KeePassX имеет функцию очистки буфера через х секунд после копирования пароля (либо замену содержимого на мусор вида ******), в случае с выключенной историей — проблемы нет, а вот со включенной есть.
Вот, вроде крутая и удобная функция, а для параноиков не продумали. Не пользуюсь ей ровно по одной причине: Нельзя «игнорировать» приложения, история которых будет оседать в этом буфере. У меня, например, KeePassX с шифрованой базой для паролей используется и факт того, что все пароли во-первых, попадают в историю, а во-вторых, утекают в облако, меня вообще не радует.
Тут видите как получилось.
Пока Boeing вату катал, Airbus выкатил A320 Neo.
Улучшения топливной эффективности добились вполне логичным способом - увеличением размера двигателя.
Но это ладно, главное было то, что на A320 Neo не надо было перучивать пилотов, совсем.
И "эффективные" менеджеры поставили перед инженерами такую же задачу, причем сделать надо было еще вчера, потому что Neo уже собирает заказы.
Понятно, что MCAS - костыль, у Boeing в обычном 737 двигатель сплющен, а тут его еще увеличивать пришлось.
И вот тут пазл, к сожалению, складывается.
Вместо здравой и верной оценки, что большой двигатель на текущий планер нормально не встает был придуман костыль (MCAS). Либо оценка не была дана (в чем я сомневаюсь), либо менеджмент ее проигнорировал (в это мне верится больше).
О MCAS умалчивают, потому что иначе это обязательная переподготовка пилотов, а надо быть как конкурент, не хуже! (Но на бумаге, а не на деле).
И поскольку сделать надо было еще вчера на процедуры разработки и тестирования... ну вы понимаете.
Boeing в принципе более архаичный и древний на фоне Airbus с его fly-by-wire, так что для них такое нововведение оказалось слишком серьезным.
Эффективные менеджеры во всей их красе.
За 7 лет работы в IT сфере понял, что они являются ничем иным, как раковой опухолью индустрии.
К огромному сожалению, эти бездари добрались и до авиации.
Я не задавался этим вопросом, так что при всем желании не могу Вам на него ответить.
Но, множество IT компаний сейчас предлагают релокацию в свои офисы за пределами РФ.
Я думаю, это самый простой способ, потому что множество проблем уже решили за вас.
На истину в последней инстанции, само собой, не претендую, и могу быть неправ.
Я уехал оттуда, поскольку был там временно, а не с целью ПМЖ. Так что по решению, к сожалению, не подскажу.
Мне главное результат, критерем которого является "Нужное мне работает".
Скатывать все в политику и срач я не собираюсь, мне это не интересно.
Знаю, поскольку столкнулся с этим в Узбекистане, там он задушен намертво.
Хоть и нужен был по работе, а не с целью обхода чего-то.
Но в реалиях "сегодня, здесь и сейчас" оно работает.
А там будем решать проблемы по мере их возникновения.
Заметил на Мегафоне еще месяц назад.
На какое-то время помогла смена порта с дефолтного для OpenVPN на рандомный.
Потом легло и оно. В итоге переехал на WireGuard, поднимается едва-ли сложнее, пока работает.
К анти-привовчникам себя не отношу, сам переболел чуть больше месяца назад, обоняние почти не задело, а вот слух сильно проседал дня на 4, в общем и целом перенёс достаточно легко, но знаю людей, которым повезло сильно меньше, увы. Что сказать хочу, спасибо Вам за статью, как минимум за огромные труды, которые были положены в исследование информации для её написания. Просто спасибо.
А, пардон, я неправильно трактовал ваше сообщение, я думал у вас только мышка не кликается, а клавиатура работает, тогда да, такое себе. Кстати, всё же, переход в другое tty тоже не работает? (Ctrl+Alt+F 1 2 3...)?
Так это, journalctl и dmesg никуда вроде из live образа не деваются.
Для показа Snackbar'a в примере со вторым приложением я тоже использовал middleware. Он следил за единственным интересующим его событием и показывал сообщения, когда что-то прилетало. Я примерно понимаю что Вас смущает в случае с событием DataUpdated, то, что оно пролетит через все Middleware и другие Reducer'ы, потенциально давая возможность прострелить колено, но, в этом весь Redux, это фундаментальный его механизм, сложно будет сделать иначе не нарушив изначальную идею.
Зависит от ситуации. По принципу вынести что-то в общий commons модуль, а остальное в другие — нормально. Если речь про feature модули, тут, к сожалению, подсказать не могу, ввиду отсутствия опыта в реализации подобного подхода.
Да, последовательность действительно имеет значение в данном случае и я бы даже сказал, что надо быть внимательным, но, это редко создаёт проблему, если правильно к этому подойти. Как правило у Вас будет мало случаев, когда несколько разных Middleware следят за одним и тем же событием и пытаются его заменить на что-то другое. Шанс выстрелить себе в ногу, конечно, всегда есть, но больших проблем я особо не заметил, да и логика эта хорошо покрывается тестами, что даёт большую уверенность в отсутствии регрессий. Отличный вопрос, кстати.
Я приводил пример подхода чуть ниже в ответ на другой комментарий. Вкратце — зависит от того, как Вы построите состояние. Моё мнение в чем: При другом подходе данных меньше у Вас не станет, они просто будут разбросаны по всему приложению, часть во фрагменте, часть в интеракторе, часть ещё где-то и т.д.
В случае с Redux они просто лежат в одном месте, а всё остальное эти данные только использует, но не хранит.
В более сложной конструкции части ApplicationState описываются иначе.
Например как-нибудь вот так:
При этом BottomSheetState и CurrentScreenState могут являться sealed классами с явно ограниченным количеством возможных вариантов
BottomSheetState.kt
CurrentScreenState.kt
Т.е. получается что у нас есть стейт какого-то BottomSheet'a или конкретного экрана и в момент времени активным может быть только один из. Но в тоже время в ApplicationState рядом могут лежать и другие данные, которые каждый может дергать на любом экране. Мне кажется, что в целом это баланс, между работоспособностью и достаточно простым на восприятие состоянием. Создатели Redux на JS в одной из частей документации даже описывают подход, как лучше структурировать состояние. Вкратце — более плоское состояние — лучше, сильно много вложенностей усложняют работу с такой конструкцтей.
Если под дроблением вы имели ввиду что-то другое и я не до конца ответил на Ваш вопрос — дайте пожалуйста знать, подискутируем.
Speaking seriously, I recently installed a licensed Windows 10 from an official USB drive and immediately after installing I'm trying to update my system but it constantly fails to install update. It was build 19** and I didn't have a chance to upgrade to the latest 20H2 version. I've spent 3 hours, 3, damn, hours, trying to install this update to clean and official installation of the Windows 10 and ended up using the Update Assistant. It seems to me that Windows is fundamentally broken, unfortunately. It's not acceptable for the system to behave in this way.
It's just my opinion, I'm not a fan of a particular OS, because the main thing that system should do — is to solve my problems, but when we talking about Windows I have a strong feeling that I'm constantly fight with the system instead of using it.