Оные органы ответят, что у вас тут налицо спор хозяйствующих субъектов, и дорога вам в арбитраж (если юрик) или в райсуд (если физик), а органам некогда — митинг разгонять пора…
В комментах уже писали, что это стандартная фраза, и она ничего не значит. В следующий раз подключат что-то другое. У человека в прошлый раз так же подключали «Персонального ассистента», и тоже обещали «никогда больше...». :-(
Вот, да — «Персональный менеджер» был прошлой бизнес-идеей этих товарищей. Видимо, народ начал возмущаться и возвращать деньги обосновывая это тем, что услуга подключалась без их ведома и они ей не пользовались. С антивирусом сделано хитрее — это не такая эфемерная услуга, и оспаривать по основанию «не пользовались» будет несколько сложнее…
Моя личная точка зрения заключается в том, что линейный («процедурный») способ описания реальности — для человека является естественным. Можно долго рассуждать об этом, но поскольку структура почти всех языков построена по схеме «подлежащее-сказуемое» — видимо, это как-то соответствует биологическим структурам в голове человека.
При этом, синтаксис streams имеет два неоспоримых преимущества:
— Когда вы декларируете явным образом операцию (map/filter/reduce/etc) и преобразование (ссылкой на предопределенную лямбду), у компилятора и jit есть больше шансов догадаться поставить в этом месте intrinsics, а то и развернуть в векторные инструкии SSE/AVX. Сколько-нибудь сложный цикл с if такой оптимизации не подлежит.
— Когда применяемое преобразование становится first-class object — вы получаете возможность его передавать. И это прямой путь к переносу нагрузки на GPU/кластеры/whatever.
Если же вы не имеете такого объема данных, чтобы его надо было ускорять векторной обработкой или параллельными вычислениями — я не вижу смысла вешать еще один уровень абстракций между линейной бизнес-логикой и кодом. Как минимум, код без лямбд легче отлаживается. Кроме того, иногда хочется куда-то в середину воткнуть операцию, не относящуюся напрямую к потоку данных. Это может быть журналирование, это может быть обращение к Performance-counter, или периодический flush()/clear() сессии Hibernate, чтобы избежать катастрофического падения производительности и распухания внутреннего кэша ORM.
В целом, у нас в разработке есть консенсус-мнение, что streams и лямбды в java очень похожи на template-metaprogramming в современном C++: хорошо для специфических применений, но прежде чем пихать в свой код — нужно взвешивать риски и потенциальную выгоду. Your mileage may vary…
Самое забавное — это что от переписывания на Optional и stream-подобный синтаксис, количество строк кода не сильно изменилось. И если код с «if» мог читать любой разработчик средней квалификации, то новый — только тот, кто дополнительно держит в голове stream-api. Понятно применение streams и лямбд там, где потенциально можно ускорить обработку большого объема данных в многопоточной среде. В бизнес-логике оно зачем нужно? Создается впечатление, что новую фичу языка толкают не от большой нужды, а потому что модно…
Замечание раз: надо посмотреть не только потребление в активном режиме, а еще — какие там есть режимы сна, и как оно из них выходит? Это важно для батарейных и автономных применений.
Замечание два: ардуина хороша бывает тем, что ты можешь сначала отработать алгоритм на большой плате (с роскошью в виде отладочных сообщений в Serial), а потом перенести на кастомную плату с мелкой тинькой (tn85, tn13, tn2313...)
Следующим этапом заводятся классы типа GenericContext (или NVPL — name-value pair list), и все описанные классы делаются Configurable из GenericContext-а. Потом пишутся адаптеры на GenericContext из XML и JSON. В результате, получается приложение с функционалом, определяемым конфигурацией. Это очень мощная и красивая вещь, но надо понимать, что в какой-то момент конфигурация становится этаким специфичным (в клинических случаях — тьюринг-полным) языком программирования, описывающим существенные свойства классов и их взаимоотношения. Если это не пугает и оправдано сложностью решаемой задачи — почему бы и нет? На Java можно посмотреть в сторону Spring, где через XML-файл (или аннотации) можно вшивать одни Beans (экземпляры классов) в другие. Так вот, людей которые могли бы («с нуля», не с шаблона или предыдущей версии) написать конфиги spring/hibernate/maven — оказывается, не так и много! :-)
Блин, экономия на отсутствии ПЕЧКИ — это даже не смешно. Если не считать странного сценария, когда принтер постоянно печатает — общее потребление энергии устройством будет в основном определяться потребляемой мощностью на холостом ходу. А это — вопрос цены и схемотехники блока питания, но никак не технологии печати… С другой стороны — пьезоголовка, которая выплевывает микрокапли чернил является довольно тонким и сложным инструментом, в котором для удовлетворительного отпечатка ВСЕ дюзы должны работать штатным образом. А их довольно много! Монохромный лазерник принципиально проще по конструкции. Ну да, есть печка — но технология построения регулируемых нагревателей человечеству давно и хорошо известна! Зато все тонкие узлы — типа лазерной развертки — с бумагой не контактируют и в процессе нормальной эксплуатации почти не изнашиваются. А то что контактирует — принципиально не сложное и дорого не стоит (если только «продать принтер дешево, запчати и расходники дорого» не является политикой производителя). И да, я понимаю, что делая тесты — производитель может доказать что люди ходят на руках и что люди ходят на головах (вы же не верите цифрам расхода топлива в буклетах автопроизводителей, правда ?). В реальной жизни нужен очень специфический сценарий использования принтера, чтобы монохромная струйная печать на круг вышла сколько-то значимо дешевле монохромной лазерной. И если лазерники вовсю живут за пределами гарантии (у меня дома до сих пор печатает HP1018, которому скоро стукнет 20 лет), то негарантийный ремонт «струйного чуда» будет стоить в 70-80% стоимости нового аппарата — и чудо будет проще выкинуть…
Это кажется проявлением общей тенденции перехода от «инженеров-разработчиков» к «разработчикам-кодировщикам». Раньше — инженерам (или группе инженеров) поручали задачу. Из реального мира! И они несли ответственность за ее решение вплоть до сопровождения производства. Сейчас есть тенденция рядовых разработчиков держать на формате «взял таску, закрыл, перебросил в QA, часы забукал». Это с одной стороны, позволяет зайдействовать больше разработчиков с низкой квалификацией (потому что нажимать на кнопки они могут, а думать и проектировать — еще нет). С другой — это требует прослойки архитекторов/декомпозиторов/техлидов/ревьюверов чтобы с одной стороны разжевывать задачи до элементарных тасков, а с другой — чтобы создаваемое нечто подчинялось хоть какой-то закономерности и стандартам качества. Лично мне ближе подход Брукса — программирование похожее на операционную бригаду. Или технология мастер-подмастерье у художников: мастер широкими мазками набрасывает картину, а менее умелые подмастерья отрисовывают детали (одновременно обучаясь на примере мастера и более способных коллег-подмастерьев). Идея программирования как конвейера — как-то не вдохновляет… :-(
Лично я — за то, чтобы уметь что-то кроме высокоуровнего программирования. Понадобилось нам как-то эмулировать на мелком и медленном контроллере внешний АЦП mcp3201… А скорости контроллера не хватает — но две микросхемы 74-й серии (сдвиговый регистр и 4xИ-НЕ) полностью решили этот вопрос. Понятно, можно было бы контроллер взять получше-побыстрее — и в серии так бы и поступили, вероятно. Но когда надо быстро-быстро и здесь-сейчас, «устаревшие» технологии могут быть весьма кстати…
Составление хорошего теста — который проверяет то, что хочется проверить — это адски сложная работа. Во-первых, необходимо найти корректную (полную и непротиворечивую) формулировку вопроса. Например: «Безопасным для жизни напряжением является: a) 9 b)12 c) 24 d) 120 e) 240 вольт». Тут целая куча всяких если: помещение сухое или влажное, ток постоянный или переменный, средства защиты есть/нет, и т.д. Все это учитывать — вопрос будет нечитаемый. Поэтому его формулируют так: «Согласно п.X документа Y… и далее по-тексту». То есть мы подменяем реальное знание о безопасном для жизни напряжении знанием того, что написано в неком документе по этому поводу. Далее, в большинстве случаев разумные ответы могут быть выведены из общих знаний. Чтобы этому противодействовать, авторы тестов начинают дробить ответы: «а) 9.5 вольт, b) 10 вольт c) 12 вольт d) 14 вольт». Тут две беды. Во-первых, мир не черно-белый, и если человек запомнил вместо 12 вольт — 14, это не беда. Беда если он вместо 12 запомнил 127… Ну и до кучи, все что меньше 12 — тоже правильные ответы. Но, естественно, автор теста считает что правильный ответ один. Я не говорю, что нельзя сделать такой тест, чтобы этого идиотизма в нем не было. Но это адская работа, и я не видел чтобы кто-то реально этим заморочился. И это мы тестируем условно простые навыки. Я видел предложения тестировать программистов таким способом на профессиональные способности. Прилично на это реагировать я не могу — представьте себе, что дирижер, принимая музыканта в оркестр вместо того, чтобы тестировать то что нужно (способность играть на инструменте в составе оркестра) будет спрашивать его: «Из чего изготавливается гриф скрипки ?: a) Ольха, b) Клен, c) Дуб, d) Пластик». Что получится? Получится чушь, потому что тест не может проверить высокоуровневые навыки и способности. А там, где тест можно применить (изначально, помнится, для диагностики больных с нарушением развития психики) — для нормально развитых людей они не имеют смысла. Даже тест в автошколе, несмотря на то, что там картинки имитирующие дорожные ситуации — не проверяет умение человека водить автомобиль. Я знаю дофига опытных водителей, которые ездят годами без аварий, но допустят >2 ошибок в стандартном тесте, который сдавали при выходе с автошколы. А это, пожалуй, пример хорошего, методически правильного и проработанного годами теста… А представляете, какое гуано под видом тестов лепят образовательные учреждения и HR отделы корпораций? Ой-е-е… :-(
Есть такая давняя русская традиция: проверять не то, что нужно — а то, что легко проверить. В 99% случаев, тестом можно проверить только то, что легко — а не то, что нужно. Благая цель — сделать срез понятого и усвоенного материала вырождается в идиотизм — проверку правильного запоминания неких мелочей, так или иначе упомянутых в материале. Я сходу предлагаю авторам делать тестовые задания вроде: «на странице 36 четвертое слово в пятой снизу строчке начинается на букву: a) А, б) Г, в) Х, г) Й». Пользы для дела ровно столько же… :-(
Это правильное замечание, и у меня нет на него точного ответа. На горизонте десяти лет, по нашему опыту, это пока работает. Кардинальных сдвигов в парадигме программирования (например, все разом перешли на FP или ООП вышло из моды) пока нет. Это не гарантия, что такого не случится в будущем (кто постарше из читателей помнит, например, взлет и падение языков 4GL и Rapid Application Development, или период популярности Fortran, или Delphi...). С другой стороны, я бы сказал что есть четкая тенденция к падению квалификации приходящих в отрасль людей. Если раньше почти все условные джуны имели хоть какой-то опыт программирования «для себя» (то есть они по факту сначала заинтересовались программирлованием, а потом пошли на него учиться) — теперь я лично вижу истории типа «хотел поступать в мед, но не хватило баллов — пошел на ИТ». То есть приходят реально люди, весь опыт программирования которых составляет «одна пара в неделю». Обращаясь по аналогии к авиации — это летчики выпуска ускоренной программы военного времени (хотя у нас войны вроде как и нет...). Можно почитать мемуары командиров того периода — первая задача полка, получившего пополнение — было доучить его до минимальных стандартов, которые хотя бы гарантировали что молодые кадры не разложат технику на взлете-посадке и не потеряются при полете по маршруту (даже без воздействия противника). Аналогично я вижу ситуацию и в ИТ — теоретически, можно начать писать софт так, чтобы он был понятен даже попавшему по-ошибке в ИТ медбрату — но кто будет оплачивать эти издержки? Поэтому пока фирмы огранизуют как минимум доучивание на входе (как раз до среднего программиста), или как Яндекс — фактически создают альтернативную систему среднего профессионального образования…
Ну у летчиков-то более менее просто было: учебную программу освоил, на учебном биплане вылетел, на переходном учебном самолете часы налетал — ну все, средняя квалификация достигнута. И в принципе, это и есть какой-то общий знаменатель на который можно равняться. И да, я понимаю, что у нас сейчас каждое учебное заведение, которое готовит якобы ИТ-специалистов понимает под этим то, что ему удобно. Но в целом, в текущем мире я бы ориентировался на хорошего джуна/среднего миддла. Потому что если тело с головой до этого уровня не дотягивает — его надо учить, а не работать…
Согласен — в любой отрасли стандарт меняется. Но обычно разработчик с опытом работы, через которого уже прошла пара джунов/стажеров — интуитивно понимает уровнь людей, на которых надо рассчитывать код. В любом случае, если кому-то приходится объяснять код — это звонок что стоит один раз написать комментарий… Второе возможное упражнение — представить что тебя подняли в 03:30 по звонку, и нужно разобраться где проблема в твоем же коде (и тут ли она?). Если когнитивных способностей разработчика (с учетом пониженной работоспособности, спутанности мыслей из-за прерванного сна, и т.д.) хватает для анализа — код можно дополнительно не документировать.
Ну да, я согласен — вы строите специфическую компанию. Однако, не представляю, если честно, как это можно распространять в сколько-нибудь критические области человеческой деятельности… Вся история человечества — это история специализации и кооперации. Важно, безусловно, чтобы руководитель не терял связи с основным производственным процессом организации — но обычно личностные характеристики, которые делают человека хорошим менеджером (или хорошим разработчиком) — редко совмещаются в одном физическом лице в один момент времени. Блин, давайте по аджайлу реактивный двигатель спроектируем — без четких требований и с отработкой безопасности методом последовательных улучшений! Полетите на таком? Или мост построим… Надеюсь, что при нас до такого не дойдет!..
Я приватно называю это «failed management». В моем представлении — менеджмент получает деньги за то, что взаимодействует с хаосом окружающего мира — и порождает внутри организации структуру с понятным распределением ответственности, целями, и тому подобным. Но нет, новое поколение менеджеров хочет жить в мире волшебных единорогов — поэтому вместо того чтобы работать — скидывает хаос на головы разработчиков: мол теперь живите с этим… Деньги при этом получать не перестали. Какое-то дурное устройство мира, если честно. Не знаю, в какую сторону это вырулит — но существущее положение вещей с failed management не кажется мне устойчивым.
И нет, я не против аджайла, MVP и прочих полезных вещей, но против хаоса и «маш-маш», «вась-вась» в разработке…
В авиации есть (было) понятие «доступен летчику средней квалификации». Ну то есть к ручке управления не надо приделывать табличку: «на себя — вверх, от себя — вниз». Но если особенность конструкции не очевидна летчику средней квалификации — ее надо документировать. Аналогично придерживаемся у себя. Если код написан так, что он понятен программисту средней квалификации сам по себе — дополнительных комментариев не требуется. Если код может быть не очевиден для среднего программиста (чем бы это ни было вызвано: сложностью алгоритма, особенностями аппаратуры, странными требованиями клиента) — пишется блок «почему так».
Если честно, вызывает некое раздражение даже не процесс найма, а сама корпоративная культура. Все желеобразное, все неопределенное, работа — дом, и дом — работа, критериев оценки нет — все на эмоциях, в критической ситуации — пойди пойми кто за что отвечает и кто что должен чинить…
В противовес вспоминаются времена почтенных джентльменов из IBM. Это когда инженеры приезжают на работу на дорогих машинах, весь день делают исключительной новизны и сложности вычислительные системы, вечером прощаются и разъезжаются чтобы встретиться снова утром (или после уикэнда). И даже самому последнему менеджеру понятно, что устраивать тут корпоративные игрища или тимбилдинги (или оценки эмоциональной вовлеченности) — не рекомендуется. Высокооплачиваемые профессионалы ДЕЛОМ заняты — если они захотят поиграть в футбол (или напиться), договорятся после работы и поиграют (напьются). А за «мешают работать» могут и с лестницы спустить, если что… :-)
С третьей стороны, лучше уж на этапе найма показывать как оно у вас внутри устроено. Кому-то может быть и комфортно в таком вариться…
При этом, синтаксис streams имеет два неоспоримых преимущества:
— Когда вы декларируете явным образом операцию (map/filter/reduce/etc) и преобразование (ссылкой на предопределенную лямбду), у компилятора и jit есть больше шансов догадаться поставить в этом месте intrinsics, а то и развернуть в векторные инструкии SSE/AVX. Сколько-нибудь сложный цикл с if такой оптимизации не подлежит.
— Когда применяемое преобразование становится first-class object — вы получаете возможность его передавать. И это прямой путь к переносу нагрузки на GPU/кластеры/whatever.
Если же вы не имеете такого объема данных, чтобы его надо было ускорять векторной обработкой или параллельными вычислениями — я не вижу смысла вешать еще один уровень абстракций между линейной бизнес-логикой и кодом. Как минимум, код без лямбд легче отлаживается. Кроме того, иногда хочется куда-то в середину воткнуть операцию, не относящуюся напрямую к потоку данных. Это может быть журналирование, это может быть обращение к Performance-counter, или периодический flush()/clear() сессии Hibernate, чтобы избежать катастрофического падения производительности и распухания внутреннего кэша ORM.
В целом, у нас в разработке есть консенсус-мнение, что streams и лямбды в java очень похожи на template-metaprogramming в современном C++: хорошо для специфических применений, но прежде чем пихать в свой код — нужно взвешивать риски и потенциальную выгоду. Your mileage may vary…
Замечание два: ардуина хороша бывает тем, что ты можешь сначала отработать алгоритм на большой плате (с роскошью в виде отладочных сообщений в Serial), а потом перенести на кастомную плату с мелкой тинькой (tn85, tn13, tn2313...)
И нет, я не против аджайла, MVP и прочих полезных вещей, но против хаоса и «маш-маш», «вась-вась» в разработке…
В противовес вспоминаются времена почтенных джентльменов из IBM. Это когда инженеры приезжают на работу на дорогих машинах, весь день делают исключительной новизны и сложности вычислительные системы, вечером прощаются и разъезжаются чтобы встретиться снова утром (или после уикэнда). И даже самому последнему менеджеру понятно, что устраивать тут корпоративные игрища или тимбилдинги (или оценки эмоциональной вовлеченности) — не рекомендуется. Высокооплачиваемые профессионалы ДЕЛОМ заняты — если они захотят поиграть в футбол (или напиться), договорятся после работы и поиграют (напьются). А за «мешают работать» могут и с лестницы спустить, если что… :-)
С третьей стороны, лучше уж на этапе найма показывать как оно у вас внутри устроено. Кому-то может быть и комфортно в таком вариться…