Как показывает опыт, гравитационная вытяжка в многоквартирных домах либо имеет недостаточную производительность, либо тупо перестает работать летом, а иногда и вовсе «опрокидывается». Для качественного воздухообмена как минимум вытяжка должна быть принудительной и не в общий вентканал.
Я на 4.2 еле дождался загрузки гугл плея чтобы отключить автообновление приложений. Загрузки Хабра в хроме просто не дождался. Хотел использовать как читалку, но скроллинг pdf вызывает кровь из глаз ((
Имею двух таких зверей в закромах. Один - обычный tf300tg, а второй уже комплектно с клавой. Тот, который с клавой, был заброшен лет пять-семь назад и, кажется, даже остался на стоковой 4.2 (если не 4.1). Его бесклавиатурного собрата я год назад пытался оживить, накатывая на него разные варианты кастома от KatKissa, получая регулярные бутлупы, перезагрузки и прочие прелести)) все как надо) даже пробовал откатить его на сток 4.2. Но дикие тормоза смазали всё впечатление. То ли в начале 2010-х трава зеленей была и железо казалось быстрей, то ли что-то в нем подустало за это время. В итоге прошил его до работоспособного состояния 6.0 плюс гаппсы, офигел от тормозов и убрал в дальний ящик. Зато поностальгировал))
Немного отвлеченный вопрос про углеродный след и его снижение. Приведен даже слайд с разницей в 10 раз между платформой на С/С++ и платформой на пхп/питоне/руби. А где оценка углеродного следа во время разработки этой платформы? Видится мне, что по энергозатратам на разработку сравнение будет не в пользу С++.
В целом, согласен. Разве что, исходя из контекста статьи, все же это были не талмуды, а скорее специализированная документация типа учетной политики банка или положений ЦБ РФ, которые подрядчик на таком проекте должен знать наизусть. Область-то зергулирована по самое небалуйся.
А когда Миша в роли заказчика рассказывает подрядчику как этому подрядчику делать его, подрядчика, работу — это как? Вроде бы подрядчик знал, на что шел и контракт подписывать их никто не заставлял. С чего заказчик должен им еще и базовые вещи объяснять? А в статье, походу, ситуация именно такая.
Если вчитаться в текст статьи, то можно увидеть, что человек этот — представитель заказчика, непосредственно принимающий участие в приемке работ подрядчика. Так что условная «команда» для него скорее наемные рабочие, чем коллеги. И в случае с крупным банком таки да, указание читать нормативные акты является абсолютно правильным, ибо разжевывать их положения ни в ТЗ, ни непосредственно команде подрядчика никто не обязан.
Если посадить квалифицированную команду, занимавшуюся разработкой системы управления складом, за разработку (или модернизацию) автоматизированной банковской системы, то в чем будет нормальность подобной ситуации и как поможет их квалификация? Пример гипотетический, но для интеграторов такие случаи — не редкость.
Низкая толерантность профессионала к некомпетентным подрядчикам вряд ли может быть истолкована как нелояльность. И компании Миши это только на руку. Зачем от него избавляться?
А нужна ли такая команда, которая приходит на крупный проект не имея четкого понимания как это должно работать? Пока складывается впечатление, что на проект взяли отряд эдаких «неженок», которым надо все разжевать и положить в рот, а любая конструктивная критика воспринимается в штыки. И, кстати, раз уж это про банк и инфраструктуру, то почему описано только взаимодействие РП с заказчиком, где были в это время аналитики подрядчика и были ли они вообще?
Жалко, что автор оставил один комментарий и слился с темы. Интересно было бы узнать поподробней.
Там, в начале статьи, вводные про инфраструктуру крупного банка. Как думаете, кто первый получит по башке за запуск «не идеального с косяками на старте» продукта? Потенциальные масштабы проблем для заказчика представляете? Это не мобильный почтовый клиент, где можно написать «ой, упс, мы облажались — нате вам багфикс». За висящий процессинг или криво/невовремя сданную отчетность банк рискует получить по шапке от ЦБ и аудиторов.
Поэтому условный «Миша» все делает правильно — раз подрядчик пришел на этот проект, значит взял на себя некие обязательства, и отмазки в стиле «че вы к нам придираетесь, работаем как умеем» не прокатят.
Не спорю, такой подход вполне вероятен, но далеко не везде. Кстати, я не писал с чьей стороны такой подход взят за правило — в данном случае это непринципиально. Важно, что несогласие с таким неформальной концепцией может быть воспринято с удивлением))
При этом, в определенных сферах, сырой релиз «еще вчера», особенно возведенный в правило, может быть череват повышенным вниманием регулятора, штрафом, а то и чем похуже.
Понятно, что, например, мобильную морду к сервису можно выкатить и с косяками, будь то продукт стороннего заказчика, либо свой собственный. Наглядным примером могут служить релизы один за одним вполне популярных, например, приложений под iOS с комментариями к релизу «поправили еще немного багов»))
Собственно, да. Со стороны этот эпизод выглядит, как попытка подрядчика через свое руководство продавить заказчика на принятие сырого недодела, но в срок. Как только попытка вскрылась, подрядчику было указано на качество его работы, что было воспринято как обида, уж не знаю, действительно ли ввиду низкой квалификации команды и неготовности к критике или по другим причинам.
Вообще, на мой взгляд, подобные опусы из-под корпоративного аккаунта скорее заставляют лишний раз задуматься, нежели посочувствовать героической команде, прорывающейся к свету сквозь монстров-заказчиков.
Модель поведения из статьи выходит тоже весьма субъективно описанной. Согласитесь, что у одного и того же человека может быть совершенно разная реакция на вопросы другого человека, в зависимости от того, например, как часто и в какой форме эти вопросы задают.
А что касаемо подобных персонажей, то, в свое время подобный «токсичный Миша» меня неплохо прокачал в новой для меня предметной области, в том числе и с использованием всех тех «негативных» практик, описанных в статье. Вопрос всего лишь в отношении к процессу, понимании цели и умении общаться с людьми, отделяя зерна от плевел.
Мы не знаем всей правды. И встречных вопросов мы не знаем. И обида автора на то, что его ткнули этими вопросами в его некомпетентность вполне может оказаться именно этим — некомпетентностью и неспособностью ответить на вопросы по своему проекту, задекорированные под обиду на токсичного заказчика.
У любого диалога две стороны, на мы стараемся весьма ограниченную информацию одной из сторон экстраполировать на вторую, что порочно и неверно))
А может, наоборот, это квалифицированный и опытный спец, на которого (возможно, против его воли) повесили сопровождение разработки подрядчиком? При этом на подрядчика у этого Миши может не быть прямого влияния, а за результат работы спросят все равно с него. И такие ситуации нередки ведь.
Там, в тексте, были ключевые слова «ключевой персонаж на стороне заказчика», а проектная команда, видимо, по привычке, перепутала его со своим ментором. Заказчик не должен разжевывать понятия из нормативных документов подрядчику, который пришел на этот проект. Разжевывать стоит особенности системы/процессов этого заказчика для лучшей интеграции продукта. И искать поехавшую ячейку ему тоже может не очень захотеться, потому что это задача подрядчика отчитаться качественно и в срок, а не или-или. Даже если заказчик — условно соседний департамент, а не другая организация.
Почему-то в последнее время все чаще встречается практически узаконенное право на ошибку при разработке почти любого продукта (сначала зарелизим, а потом допилим фиксами за пару месяцев) и при неприятии такого подхода заказчиком возникает стойкое непонимание происходящего и желание страшных анальных кар тому, кто не хочет такую работу принимать.
Это, как раз, прекрасный случай для демонстрации полезности развитых т. н. «софт скиллов». И если у команды и Миши общая цель, то можно вспомнить, что Миша — тоже человек со своими особенностями, а не ресурс или юнит, и постараться подобрать к нему подход ради общего блага, а не эскалировать на руководство посыл «он токсичный, сделайте с ним что-нибудь».
Вообще, если честно, выглядит все это как столкновение олдскульного аксакала (или зубра) с активной, но неопытной в предметной области командой, для которой соблюдение дедлайнов важнее правильного результата, хоть и ценой лишних итераций.
С того, что вентилятор в приточке это не насос. Какое избыточное давление он может создать?
Как показывает опыт, гравитационная вытяжка в многоквартирных домах либо имеет недостаточную производительность, либо тупо перестает работать летом, а иногда и вовсе «опрокидывается». Для качественного воздухообмена как минимум вытяжка должна быть принудительной и не в общий вентканал.
Все уже давно придумано за нас) Есть же гениальная статья от FAKE GRIMLOCK как раз в тему!
https://readwrite.com/fake-grimlock-win-like-stupid/
Я на 4.2 еле дождался загрузки гугл плея чтобы отключить автообновление приложений. Загрузки Хабра в хроме просто не дождался. Хотел использовать как читалку, но скроллинг pdf вызывает кровь из глаз ((
Имею двух таких зверей в закромах. Один - обычный tf300tg, а второй уже комплектно с клавой. Тот, который с клавой, был заброшен лет пять-семь назад и, кажется, даже остался на стоковой 4.2 (если не 4.1). Его бесклавиатурного собрата я год назад пытался оживить, накатывая на него разные варианты кастома от KatKissa, получая регулярные бутлупы, перезагрузки и прочие прелести)) все как надо) даже пробовал откатить его на сток 4.2. Но дикие тормоза смазали всё впечатление. То ли в начале 2010-х трава зеленей была и железо казалось быстрей, то ли что-то в нем подустало за это время. В итоге прошил его до работоспособного состояния 6.0 плюс гаппсы, офигел от тормозов и убрал в дальний ящик. Зато поностальгировал))
Немного отвлеченный вопрос про углеродный след и его снижение. Приведен даже слайд с разницей в 10 раз между платформой на С/С++ и платформой на пхп/питоне/руби. А где оценка углеродного следа во время разработки этой платформы? Видится мне, что по энергозатратам на разработку сравнение будет не в пользу С++.
В целом, согласен. Разве что, исходя из контекста статьи, все же это были не талмуды, а скорее специализированная документация типа учетной политики банка или положений ЦБ РФ, которые подрядчик на таком проекте должен знать наизусть. Область-то зергулирована по самое небалуйся.
А когда Миша в роли заказчика рассказывает подрядчику как этому подрядчику делать его, подрядчика, работу — это как? Вроде бы подрядчик знал, на что шел и контракт подписывать их никто не заставлял. С чего заказчик должен им еще и базовые вещи объяснять? А в статье, походу, ситуация именно такая.
Если вчитаться в текст статьи, то можно увидеть, что человек этот — представитель заказчика, непосредственно принимающий участие в приемке работ подрядчика. Так что условная «команда» для него скорее наемные рабочие, чем коллеги. И в случае с крупным банком таки да, указание читать нормативные акты является абсолютно правильным, ибо разжевывать их положения ни в ТЗ, ни непосредственно команде подрядчика никто не обязан.
Если посадить квалифицированную команду, занимавшуюся разработкой системы управления складом, за разработку (или модернизацию) автоматизированной банковской системы, то в чем будет нормальность подобной ситуации и как поможет их квалификация? Пример гипотетический, но для интеграторов такие случаи — не редкость.
Низкая толерантность профессионала к некомпетентным подрядчикам вряд ли может быть истолкована как нелояльность. И компании Миши это только на руку. Зачем от него избавляться?
А нужна ли такая команда, которая приходит на крупный проект не имея четкого понимания как это должно работать? Пока складывается впечатление, что на проект взяли отряд эдаких «неженок», которым надо все разжевать и положить в рот, а любая конструктивная критика воспринимается в штыки. И, кстати, раз уж это про банк и инфраструктуру, то почему описано только взаимодействие РП с заказчиком, где были в это время аналитики подрядчика и были ли они вообще?
Жалко, что автор оставил один комментарий и слился с темы. Интересно было бы узнать поподробней.
Там, в начале статьи, вводные про инфраструктуру крупного банка. Как думаете, кто первый получит по башке за запуск «не идеального с косяками на старте» продукта? Потенциальные масштабы проблем для заказчика представляете? Это не мобильный почтовый клиент, где можно написать «ой, упс, мы облажались — нате вам багфикс». За висящий процессинг или криво/невовремя сданную отчетность банк рискует получить по шапке от ЦБ и аудиторов.
Поэтому условный «Миша» все делает правильно — раз подрядчик пришел на этот проект, значит взял на себя некие обязательства, и отмазки в стиле «че вы к нам придираетесь, работаем как умеем» не прокатят.
Не спорю, такой подход вполне вероятен, но далеко не везде. Кстати, я не писал с чьей стороны такой подход взят за правило — в данном случае это непринципиально. Важно, что несогласие с таким неформальной концепцией может быть воспринято с удивлением))
При этом, в определенных сферах, сырой релиз «еще вчера», особенно возведенный в правило, может быть череват повышенным вниманием регулятора, штрафом, а то и чем похуже.
Понятно, что, например, мобильную морду к сервису можно выкатить и с косяками, будь то продукт стороннего заказчика, либо свой собственный. Наглядным примером могут служить релизы один за одним вполне популярных, например, приложений под iOS с комментариями к релизу «поправили еще немного багов»))
Собственно, да. Со стороны этот эпизод выглядит, как попытка подрядчика через свое руководство продавить заказчика на принятие сырого недодела, но в срок. Как только попытка вскрылась, подрядчику было указано на качество его работы, что было воспринято как обида, уж не знаю, действительно ли ввиду низкой квалификации команды и неготовности к критике или по другим причинам.
Вообще, на мой взгляд, подобные опусы из-под корпоративного аккаунта скорее заставляют лишний раз задуматься, нежели посочувствовать героической команде, прорывающейся к свету сквозь монстров-заказчиков.
Модель поведения из статьи выходит тоже весьма субъективно описанной. Согласитесь, что у одного и того же человека может быть совершенно разная реакция на вопросы другого человека, в зависимости от того, например, как часто и в какой форме эти вопросы задают.
А что касаемо подобных персонажей, то, в свое время подобный «токсичный Миша» меня неплохо прокачал в новой для меня предметной области, в том числе и с использованием всех тех «негативных» практик, описанных в статье. Вопрос всего лишь в отношении к процессу, понимании цели и умении общаться с людьми, отделяя зерна от плевел.
Мы не знаем всей правды. И встречных вопросов мы не знаем. И обида автора на то, что его ткнули этими вопросами в его некомпетентность вполне может оказаться именно этим — некомпетентностью и неспособностью ответить на вопросы по своему проекту, задекорированные под обиду на токсичного заказчика.
У любого диалога две стороны, на мы стараемся весьма ограниченную информацию одной из сторон экстраполировать на вторую, что порочно и неверно))
А может, наоборот, это квалифицированный и опытный спец, на которого (возможно, против его воли) повесили сопровождение разработки подрядчиком? При этом на подрядчика у этого Миши может не быть прямого влияния, а за результат работы спросят все равно с него. И такие ситуации нередки ведь.
Там, в тексте, были ключевые слова «ключевой персонаж на стороне заказчика», а проектная команда, видимо, по привычке, перепутала его со своим ментором. Заказчик не должен разжевывать понятия из нормативных документов подрядчику, который пришел на этот проект. Разжевывать стоит особенности системы/процессов этого заказчика для лучшей интеграции продукта. И искать поехавшую ячейку ему тоже может не очень захотеться, потому что это задача подрядчика отчитаться качественно и в срок, а не или-или. Даже если заказчик — условно соседний департамент, а не другая организация.
Почему-то в последнее время все чаще встречается практически узаконенное право на ошибку при разработке почти любого продукта (сначала зарелизим, а потом допилим фиксами за пару месяцев) и при неприятии такого подхода заказчиком возникает стойкое непонимание происходящего и желание страшных анальных кар тому, кто не хочет такую работу принимать.
«Нормально делай — нормально будет»))
Это, как раз, прекрасный случай для демонстрации полезности развитых т. н. «софт скиллов». И если у команды и Миши общая цель, то можно вспомнить, что Миша — тоже человек со своими особенностями, а не ресурс или юнит, и постараться подобрать к нему подход ради общего блага, а не эскалировать на руководство посыл «он токсичный, сделайте с ним что-нибудь».
Вообще, если честно, выглядит все это как столкновение олдскульного аксакала (или зубра) с активной, но неопытной в предметной области командой, для которой соблюдение дедлайнов важнее правильного результата, хоть и ценой лишних итераций.