Ох какой песец… Как вы читали Голдратта если потом пытаетесь "увеличить коэффициент использования энергии" в общем, хотя до этого говорили что метод "бутылочного горлышка" состоит как раз в противоположном — улучшение малыми затратами одного места, а не попыток улучшить везде и всё?
Заголовок — желтуха, как вот эта хрень связана с agile и lean вообще непонятно. Изобрели очередное громкое слово для недоруководителей.
Что потом подкрепляется словами "Нет необходимости «внедрения методологии и философии»". Т.е. вы натянули рефлексы собаки Павлова на человека и утверждаете что решили все проблемы, моментально, без побочных эффектов и без необходимости помочь и научить людей думать по-другому? Трешачок.
Как же я рад что появился флексбокс. Запоминать всю эту ненужную ерунду из десятков никак не связанных исключений — если у вас padding != 0 и есть border и у родительского элемента position не static и если третья пятница месяца — то тогда у вас что-то получится… С появлением флексбокса на все это можно положить болт и просто получать всегда прогнозируемый результат.
Только сейчас отправка вообще не работает.
Access to XMLHttpRequest at 'https://slowpochta.ru:9080/api/message/' from origin 'https://slowpochta.ru' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Я в итоге пришел к схеме:
1 SSD для системы
2 HDD с данными (разными).
Всё это еженедельно бекапится акронисом — SSD и первый хард — на второй, а второй хард — на первый.
SSD если умирает, выкидываешь, покупаешь новый, разворачиваешь акронис — вуаля, у тебя за полчаса рабочая система с новым диском. Данные при этом не затронуты, софт каждую неделю не ставишь — так что не теряется вообще ничего.
Ну а если умирает один из жестких (что происходит гораздо реже) — в принципе то же самое. Но это за ближайшие 10 лет было только пока один раз, т.к. HDD не системные — в работе они гораздо меньше, износа мало. При этом система работает на быстром SSD, все плюсы скорости загрузки и работы остаются.
Остаётся только при каждом обновлении наращивать объем дисков про запас… Начинал я когда-то с SSD на 64гб, сейчас уже 512 стоит. Жесткие были по 512, сейчас по 4ТБ.
У меня самый дешевый китайский xRobot (без постройки схем помещений и т.п.), брал пару лет назад за 6к вроде, чисто на пробу, в достаточно большую трёшку.
Теперь понимаю что во всех квартирах буду заводить 100%. Уборка пылесосом превратилась из еженедельного занятия — в "раз в месяц или реже пройтись по плинтусам быстро". Мастхэв, экономит тонну времени, пол всегда чистый.
Кстати, про подтверждение личности сканом паспорта — в Москве уже 20 или более каршеринг компаний… И везде надо отослать одинаковые фотографии паспорта, ВУ, и т.п. После 3-его раза это ОЧЕНЬ надоедает.
У вас проект под угрозой? У меня — нет, не писал такого. Просто приходится в случае прыгунов делать лишнюю работу и "жонглировать" доступными ресурсами. Критичного ничего нет, но т.к. дефицита кадров на рынке нет — проще их не брать и всё.
Вообще — что мешает «закабалить» человека?
Зачем этим заниматься? На рынке полно специалистов, мне проще проигнорить скакунов, чем тратить на них время и "пытаться удержать".
«я работаю на контору А, получаю 1000$, завтра мне Контора Б предлагает 1500$ за тот же пул обязанностей. Смысл сидеть в Конторе А?»
А с чего вы взяли что у нас проблемы с ЗП либо ненормированный рабочий график? Какой-то комментарий целиком на домыслах.
В целом, если человек просто продает время — то естественно он убежит как только ему помашут купюрой. Тогда он тем более не нужен. В разработке интересны люди которые видят в работе ещё что-то помимо денег — самореализацию, проф. развитие, команду и т.п. А если он ради лишних 10 тыс. р. при зарплате в рынке готов всё бросить и бежать — еще раз подтверждаю свой тезис — на хрен он не нужен.
Если в России ещё нормально, когда ты работаешь по году в каждой конторе
Интересно это где нормально? На фрилансе? Во всех крупных конторах (вспомнить хотя бы пост по-моему Baidoo об обучении недельной давности на хабре) срок входа человека в разработку — месяца 3. И только потом он начинает приносить какую-то пользу, и еще месяца 3 окупает то что в него инвестировали. И дальше полгодика работы?
Пару раз наняв таких "прыгунов" я даже больше не звоню людям, если на последних 2-х местах работы у них ~год или меньше. Только наймешь, захочется долгосрочно запланировать ресурсы — а человека раз и нет. Пустая трата времени.
Пара тысяч долларов? Если бы. Один адаптивный круиз стоит ~150к, оптика — столько же и т.п. По крайней мере так у audi, bmw не интересовался, но подозреваю всё то же самое. 3 ляма автомобиль и еще 2+ ляма — допы.
И это уровень хабра? И в топе комментов продолжение поста с возмущением вместо ответа автору "сам дурак"?
Вы действительно думаете что вам в JS должны генерить последовательность чтобы вы вот так нажали F12 и скорректировали на выигрышную? Я думал это очевидно, что всё генерится на сервере исходя из соображений безопасности. И для экономии ресурсов естественно просто генерируется вся последовательность, вместо того чтобы гонять десятки запросов просто так. Разницы помимо нагрузки и тормозов нет никакой.
При расчете вероятности в условии не написано самое важное — количество доступных видов товаров и их соотношение. А это зашито на сервере и вы это не узнаете. И поэтому дальнейшие расчеты абсолютно бессмысленны, т.к. работают по неполным условиям, поэтому высчитанная вероятность вообще может не иметь ничего общего с реальным. Может там вообще 8 товаров и красная карточка и три набрать никогда нельзя. А может из 9 — 1 красная карточка, 6 товаров №1, 1 товар №2 и 1 товар №3.
По ощущениям вообще половина забугорного интернета перестала работать — файлообменники, сайты в облаках и т.п., за исключением самых крупных сайтов. Да и то — у МС из-за недоступности одного сервера была проблема с невозможностью залогинится — бесконечный редирект.
Теперь как на минном поле — никогда не знаешь, что у тебя не откроется, сейчас вообще включил ВПН на постоянку, чтобы не думать.
Мне кажется тут ошибка таргетирования кейсов использования на мобильниках и на компьютере. Приложение делается универсальное, а кейсы использования разные.
Для мобильника — да, хороший кейс спросить что-то быстро и получить голосовой ответ без необходимости искать телефон, разблокировать и запускать приложение.
А когда я работаю за компом — поиск информации не актуален. Мне в разы быстрее вбить руками одну строчку в браузер и получить исчерпывающий ответ с вариантами, чем сперва говорить "Привет, Алиса", ждать пока распознается, потом диктовать запрос, гадать распознается или нет и получать обрывочный ответ из первых 5 слов результата. За компом актуальны вещи которые надо делать не отрываясь от рабочего процесса — запустить фоном музыку (не только Яндекс.Музыку, но и standalone приложенный, причем одной командой сразу запустить на воспроизведение определённый плейлист — и фоном, без разворачивания принудительно окна и переключения фокуса), поставить напоминание/встречу, ответить на всплывшее сообщение в телеграме (опять же сразу, без переключения контекстов), озвучить пришедшую почту и т.п.
виду абстрактную функциональность ввода вывода, которая может возвратить разные кортежи разной длины
если первая функция T1 Read >T1>() не вызывает паники то и остальные (с кортежами, типа Tuple<T1,T2,T3,T4> Read<T1,T2,T3,T4>() ) не должны, они просто логическое ее продолжение.
Вот как раз немного вызывает панику. :) Почему? Потому что в методе T1 Read<T1>() where T1: class как ты не меняй внутренности класса T1 сигнатура и контракт метода остается одинаковым. Что позволяет не переписывать тонну кода, которые с этим связано и проектировать систему внешних классов на этом интерфейсе. А вот при использовании примитивов и переменного количества аргументов как минимум это будет плыть.
Чем огромная куча DTO лучше? Она волшебным образом делает код "поддерживаемым, расширяемым и тестируемым"? Нет, просто появится кучка новых классов, которые используются в одном месте.
Если у вас классы, которые осуществляют "обмен между отдельными логическими частями" системы используются "в одном месте", то у вас где-то присутствует ошибка проектирования. Интерфейс между логическими частями должен обладать определённой стабильностью и реиспользоваться много-много раз. Иерархия DTO — наследоваться и документироваться. Скорее всего в таком случае у вас "абстракции протекают" и вы выставляете детали реализации наружу посредством динамическим "разовых" данных. В таком случае это надо прятать подальше от глаз в приватные методы/внутренности методов посредством рефакторинга, а не оборачивать синтаксическим сахаром и говорить "вот теперь норм".
Ох какой песец… Как вы читали Голдратта если потом пытаетесь "увеличить коэффициент использования энергии" в общем, хотя до этого говорили что метод "бутылочного горлышка" состоит как раз в противоположном — улучшение малыми затратами одного места, а не попыток улучшить везде и всё?
Заголовок — желтуха, как вот эта хрень связана с agile и lean вообще непонятно. Изобрели очередное громкое слово для недоруководителей.
Что потом подкрепляется словами "Нет необходимости «внедрения методологии и философии»". Т.е. вы натянули рефлексы собаки Павлова на человека и утверждаете что решили все проблемы, моментально, без побочных эффектов и без необходимости помочь и научить людей думать по-другому? Трешачок.
Набор из 100 задокументированных исключений можно назвать "строго формализованным", удобным и прозрачным к использованию — нет.
Как же я рад что появился флексбокс. Запоминать всю эту ненужную ерунду из десятков никак не связанных исключений — если у вас padding != 0 и есть border и у родительского элемента position не static и если третья пятница месяца — то тогда у вас что-то получится… С появлением флексбокса на все это можно положить болт и просто получать всегда прогнозируемый результат.
Простенький docx для печати с QR кодами:
http://bit.ly/2KivAGg
Только сейчас отправка вообще не работает.
Access to XMLHttpRequest at 'https://slowpochta.ru:9080/api/message/' from origin 'https://slowpochta.ru' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Acronis True Image 2017 сейчас, прилагался бесплатный ключик к SSD. До этого был 2014-ый вроде...
Я в итоге пришел к схеме:
1 SSD для системы
2 HDD с данными (разными).
Всё это еженедельно бекапится акронисом — SSD и первый хард — на второй, а второй хард — на первый.
SSD если умирает, выкидываешь, покупаешь новый, разворачиваешь акронис — вуаля, у тебя за полчаса рабочая система с новым диском. Данные при этом не затронуты, софт каждую неделю не ставишь — так что не теряется вообще ничего.
Ну а если умирает один из жестких (что происходит гораздо реже) — в принципе то же самое. Но это за ближайшие 10 лет было только пока один раз, т.к. HDD не системные — в работе они гораздо меньше, износа мало. При этом система работает на быстром SSD, все плюсы скорости загрузки и работы остаются.
Остаётся только при каждом обновлении наращивать объем дисков про запас… Начинал я когда-то с SSD на 64гб, сейчас уже 512 стоит. Жесткие были по 512, сейчас по 4ТБ.
У меня самый дешевый китайский xRobot (без постройки схем помещений и т.п.), брал пару лет назад за 6к вроде, чисто на пробу, в достаточно большую трёшку.
Теперь понимаю что во всех квартирах буду заводить 100%. Уборка пылесосом превратилась из еженедельного занятия — в "раз в месяц или реже пройтись по плинтусам быстро". Мастхэв, экономит тонну времени, пол всегда чистый.
Кстати, про подтверждение личности сканом паспорта — в Москве уже 20 или более каршеринг компаний… И везде надо отослать одинаковые фотографии паспорта, ВУ, и т.п. После 3-его раза это ОЧЕНЬ надоедает.
У вас проект под угрозой? У меня — нет, не писал такого. Просто приходится в случае прыгунов делать лишнюю работу и "жонглировать" доступными ресурсами. Критичного ничего нет, но т.к. дефицита кадров на рынке нет — проще их не брать и всё.
Интересно это где нормально? На фрилансе? Во всех крупных конторах (вспомнить хотя бы пост по-моему Baidoo об обучении недельной давности на хабре) срок входа человека в разработку — месяца 3. И только потом он начинает приносить какую-то пользу, и еще месяца 3 окупает то что в него инвестировали. И дальше полгодика работы?
Пару раз наняв таких "прыгунов" я даже больше не звоню людям, если на последних 2-х местах работы у них ~год или меньше. Только наймешь, захочется долгосрочно запланировать ресурсы — а человека раз и нет. Пустая трата времени.
Пара тысяч долларов? Если бы. Один адаптивный круиз стоит ~150к, оптика — столько же и т.п. По крайней мере так у audi, bmw не интересовался, но подозреваю всё то же самое. 3 ляма автомобиль и еще 2+ ляма — допы.
А в 35 если он не дятел — его уже по рекомендациям передают как руководителя отдела/департамента/архитектора из рук в руки.
И это уровень хабра? И в топе комментов продолжение поста с возмущением вместо ответа автору "сам дурак"?
Вы действительно думаете что вам в JS должны генерить последовательность чтобы вы вот так нажали F12 и скорректировали на выигрышную? Я думал это очевидно, что всё генерится на сервере исходя из соображений безопасности. И для экономии ресурсов естественно просто генерируется вся последовательность, вместо того чтобы гонять десятки запросов просто так. Разницы помимо нагрузки и тормозов нет никакой.
При расчете вероятности в условии не написано самое важное — количество доступных видов товаров и их соотношение. А это зашито на сервере и вы это не узнаете. И поэтому дальнейшие расчеты абсолютно бессмысленны, т.к. работают по неполным условиям, поэтому высчитанная вероятность вообще может не иметь ничего общего с реальным. Может там вообще 8 товаров и красная карточка и три набрать никогда нельзя. А может из 9 — 1 красная карточка, 6 товаров №1, 1 товар №2 и 1 товар №3.
По ощущениям вообще половина забугорного интернета перестала работать — файлообменники, сайты в облаках и т.п., за исключением самых крупных сайтов. Да и то — у МС из-за недоступности одного сервера была проблема с невозможностью залогинится — бесконечный редирект.
Теперь как на минном поле — никогда не знаешь, что у тебя не откроется, сейчас вообще включил ВПН на постоянку, чтобы не думать.
Это если еще гос. клиентов нет. Мы вот только год назад с трудом дропнули поддержку 9-го. Боль и унижение — объективная реальность.
Мне кажется тут ошибка таргетирования кейсов использования на мобильниках и на компьютере. Приложение делается универсальное, а кейсы использования разные.
Для мобильника — да, хороший кейс спросить что-то быстро и получить голосовой ответ без необходимости искать телефон, разблокировать и запускать приложение.
А когда я работаю за компом — поиск информации не актуален. Мне в разы быстрее вбить руками одну строчку в браузер и получить исчерпывающий ответ с вариантами, чем сперва говорить "Привет, Алиса", ждать пока распознается, потом диктовать запрос, гадать распознается или нет и получать обрывочный ответ из первых 5 слов результата. За компом актуальны вещи которые надо делать не отрываясь от рабочего процесса — запустить фоном музыку (не только Яндекс.Музыку, но и standalone приложенный, причем одной командой сразу запустить на воспроизведение определённый плейлист — и фоном, без разворачивания принудительно окна и переключения фокуса), поставить напоминание/встречу, ответить на всплывшее сообщение в телеграме (опять же сразу, без переключения контекстов), озвучить пришедшую почту и т.п.
Вот как раз немного вызывает панику. :) Почему? Потому что в методе
T1 Read<T1>() where T1: classкак ты не меняй внутренности класса T1 сигнатура и контракт метода остается одинаковым. Что позволяет не переписывать тонну кода, которые с этим связано и проектировать систему внешних классов на этом интерфейсе. А вот при использовании примитивов и переменного количества аргументов как минимум это будет плыть.Если у вас классы, которые осуществляют "обмен между отдельными логическими частями" системы используются "в одном месте", то у вас где-то присутствует ошибка проектирования. Интерфейс между логическими частями должен обладать определённой стабильностью и реиспользоваться много-много раз. Иерархия DTO — наследоваться и документироваться. Скорее всего в таком случае у вас "абстракции протекают" и вы выставляете детали реализации наружу посредством динамическим "разовых" данных. В таком случае это надо прятать подальше от глаз в приватные методы/внутренности методов посредством рефакторинга, а не оборачивать синтаксическим сахаром и говорить "вот теперь норм".