Юзер Evernote с 2011. Тоже жду окончания платной подписки в январе. У меня в работе основной юскейс создания заметок - веб-клиппер. Переключаемся в режим "Упрощенная страница", выделяем маркером суть, сохраняем. Теги проставляются автоматически. У конкурентов эта фича работает или хуже, или не на всех сайтах. Режим фотографирования документа - еще одна прекрасная фича. Автоматическая обрезка, устранение перспективных искажений, нормализация изображения. Потом даже текст распознается и ищется поиском.
Согласен с автором в том, что развитие Evernote свернуло куда-то не туда. Electron версия на десктопе (вместо прекрасно работавшей нативной), тормозящий мобильный клиент - такое простить сложно. Сейчас я почти перестал пользоваться Evernote как классической системой заметок, стало хватать файловой системы с синхронизацией и поиском, благо в современных ОС поиск стал работать очень неплохо. Но для того, чтобы быстро дернуть страницу в архив, пока использую Слона.
Что до альтернатив, то есть еще такие NAS от Synology, в комплектном софте есть DS Note, который задумывался как аналог Evernote. Есть импорт заметок с облака Evernote (год назад работал, у меня десятки тысяч заметок, все импортировались). Есть десктопное приложение на Electron с локальным кешем в файловой системе, мобильные приложения в сторах (без локального кеша). Есть веб-клиппер по образу Evernote, но не на всех сайтах работает. В целом, со скрипом, буду использовать этот продукт вместо Слона после окончания подписки.
Практикуем смешанный режим работы, с некоторым количеством присутственных дней. Процесс проектирования софта лучше движется, когда есть доступ к физическому телу архитектора/лида. Когда в контексте задачи можно подойти, обсудить что-то, он посмотрит в экран, подтянется кто-то ещё, и вот уже около доски собрался консилиум. Я, как владелец продукта, тут же присоединяюсь к таким тусовкам, чтобы добавлять бизнес-контекст где это необходимо. Подобные мероприятия экономят кучу времени. И я не имею в виду время на дорогу до офиса. Я имею в виду время на выполнение ненужных, не актуальных или некорректно сформулированных задач. Понятно, что можно тратить дополнительные усилия на оформление всего и вся, но в маленьком коллективе это не всегда возможно. И, опять же, куда девать творческую составляющую, когда результат несколько раз может перевернуться с ног на голову и обратно?
Для сравнения, у нас есть иногородние сотрудники, которые физически не могут присутствовать, и с ними приходится пользоваться всеми этими штуками типа видеосвязи и Jira/Confluence. Эффективность подобных коммуникаций заметно ниже, а драйва нет вообще. В общем, лучше иметь возможность работать в офисе, чем не иметь такой возможности. Ну, в нашем случае так точно.
В комментариях вижу боль. Трудно что-то добавить в части эмоций, поэтому досыплю немного наблюдений в части упаковки АСУТП проектов. Не скажу за производство, но, например в дорожной автоматизации проекты оформляются как строительные. ИТ составляющая присутствует одной-двумя строчками в ведомости объемов работ как "АСУ такая-то 1 штука". Разработку стараются запихнуть внутрь пуско-наладочных работ, так как в этих проектах есть только деньги за поставку лицензий, деньги за поставку железа и деньги за работы по наладке и монтажу. Если вы разработчик АСУ и хотите заработать на этой теме, то вам нужно учиться вписываться в эти условия. Как пример, возьмем подход западных людей к снаряду. Когда приходит условный Сименс, у него в цене поставки будут и лицензии, и обязательства по обучению персонала, и сертификация инженеров. К вам бизнес-классом приедет некий чувак для "шеф-монтажа" с запредельным почасовым прайсом. Вам навялят обязательства по приобретению техподдержки за жалкие 30% от цены лицензий. В общем, как в старом бухгалтерском анекдоте про составление авансового отчета за командировку, "шляпа тут, только хрен ты её найдешь".
Представьте теперь, что компания понесла все эти расходы по закупке оборудования, работ и прочего, внесла в бюджет расходы на техподдержку. А на ком теперь экономить? На том самом Васе с покоцаным ноутом, который обслуживает АСУ. Просто все деньги, которые на это были, ушли холеным румынам или словакам в фирменной униформе, а также манагерам в сверкающих офисах класса А. Так устроен мир, собственно.
Подобный перекос он глобальный. Везде самый жирный кусок будут съедать корпорации. Разница лишь в объеме ответственности, который несут корпорации за свой жирный кусок. У нас их ответственность несопоставимо меньше, а условный Вася вынужден брать на себя все косяки и недоделки. Это уже вопросы к качеству юристов и менеджеров. Западные люди очень хорошо видят некомпетентность и умело ей пользуются. В итоге их Вася за свою небольшую зарплату по сути занимается диспетчеризацией заявок и мониторингом. При этом он обучен и защищен сертификатами. А наш Вася в мыле фигачит за тот же прайс. Про рынок тут уже написали много и по делу. Постепенно люди с головой действительно будут вымываться из АСУ, одновременно с деградацией систем и уходом вендоров, что через полгода-год приведет к серьезным отказам и авариям на тех производствах, которые не успеют адаптироваться. Думаю, что кроме, может быть, нефтянки, адаптироваться не успеет никто.
На мой взгляд, нанять в проект сеньора с рынка в принципе нельзя. Можно нанять человека, который на прежней работе считался сеньором, например. И рассчитывать, что в нашем проекте он тоже сможет исполнять функции сеньора. Потому что градации "сеньорности" существуют не вообще, а применительно к конкретному проекту. Перечисленные в статье навыки, безусловно, способствуют этому и увеличивают вероятность занять сеньорскую позицию на большинстве проектов.
Как правильно писали некоторые комментаторы, существуют проекты и сеньоры на них, которым не нужны многие перечисленные навыки. Мне кажется, количество навыков - это не про конкретный проект, а про легкость перехода на другой проект.
Я не разработчик, а владелец продуктов, и для меня сеньор-разработчик это в первую очередь технологический партнер, ведущий инженер и проводник в мир разработки в рамках своего продукта или части продукта. "Сеньорность" определяется для меня двумя параметрами:
Насколько свободно человек может объясняться на понятном мне языке и выступать инструментом управления ходом разработки в части принятия правильных технических решений. Не лезть в них, а именно помогать команде принимать правильные решения путем трансляции нюансов из мира бизнеса. Чтобы пилить нужные фичи, выбирать нужные направления на развилках. На мой взгляд, сеньор это мидл, который умеет говорить понятно для бизнеса о том, чем занимается команда.
Сколько лишней работы позволил "не делать" опыт этого человека. В маленькой команде на большом проекте любой вариант что-то не делать на вес золотом. Технический кругозор сеньора дает возможность применять готовые решения, методики, фреймворки, не изобретать велосипеды там, где это возможно. Это еще одно ключевое отличие от мидла, который тоже офигенно хороший спец, но который комфортно живет в своем пузыре. Я очень люблю мидлов, они делают всю работу на самом деле. Но это их ограничение может дорого обойтись компании. Сеньор - это тот человек, который может залезть на самое высокое дерево и осмотреть окрестности.
Тут поминали некоего "архитектора" в комментариях. Для меня ИТ-архитектор - это всё же роль, а не человек. Что-то типа бизнес-аналитика, который специализируется на выявлении нефункциональных требований и планирует их реализацию. В маленьких компаниях роль архитектора берет на себя обычно сеньор по направлению в те моменты, когда это необходимо. Он же разруливает архитектурные вопросы в ходе проектирования, если они возникают.
Сейчас практически никакие. Но технически нужно готовиться к тому, что эту ситуацию все-таки разрулят на гос. уровне. То есть, каждый хитрила должен быть зафиксирован с детальностью, необходимой для составления пакета документов в суд. То есть, по аналогии с аналогичными «штрафовалками», должны соблюдаться следующие требования:
— На изображении ТС должен быть виден номерной знак, модель ТС (можно без цвета)
— На изображении должен стоять штамп с датой, временем, идентификатором камеры (отметкой места съемки)
— Камера (с ПО) должна иметь сертификат СИ и поверку как минимум по времени (чтобы нельзя было оспорить время правонарушения). Также можно получить сертификат СИ на координаты — тогда нельзя будет оспорить и место съемки, и в суде будет «железная» тройка — фото ТС, время и место.
— Должна быть исключена модификация собранных данных кем бы то ни было. Т.е., у суда должна быть уверенность, что данные поступили в автоматическом режиме, а не из фотошопа. Технически корпус камеры должен быть опечатан, фотоматериалы должны иметь ЭЦП по ГОСТу (просто ЭЦП не считается)
При этом любая аналитическая обработка, типа распознавания ГРЗ, классификации и т.п., не является доказательством в суде. Это только для удобства поиска и формирования материалов.
Сейчас существуют две схемы: 1. Оператор получает оплату за сервис, а все собранные деньги поступают «владельцу» (например, ГК Автодор). 2. Оператор собирает средства на свои счета, а соинвестору — государству поступают оговоренные в контракте фиксированные суммы (или процент).
Схема 1 сейчас доминирует. На уровне бизнес-процессов возникают существенные нюансы. Например, в случае пиковых нагрузок при схеме 1 оператор не будет открывать шлагбаумы, так как его KPI — уровень собираемости, который жестко контролируется «владельцем». По схеме 2 оператору проще пропустить людей на дорогу бесплатно, лишь бы не вызывать негатив, так как его KPI — общее количество собранных средств. Отсюда и разные подходы к управлению. При схеме 1 оператор будет держать персонал и обеспечивать отказоустойчивость, чтобы соблюсти KPI по доступности сервиса. По схеме 2 оператор будет экономить средства и принимать риски по отказу оборудования и систем с целью уменьшить OPEX. Время покажет, какая схема эффективнее, но пока судить рано.
В моей статье это проблема №2. Права оператора очень слабо закреплены законодательно. С одной стороны, он обязан обеспечить сбор денег с автомобилей в интересах госкомпании («владельца» дорог), с другой стороны, проезд ПВП без оплаты почти ничем не грозит автомобилисту. Поэтому единственным техническим средством достижения показателей остается тот самый шлагбаум. Для видео-толлинга нужны две вещи: 1. гарантия того, что выставленный счет будет оплачен и 2. Чистые номерные знаки. Как Вы понимаете, проблемы у нас по обоим пунктам. Но все идет к тому, что видео-толлинг у нас все же будет в дополнение к транспондерам.
Вы серьезно хотите обсуждать подобные вопросы в технарском топике? Ведь тут у каждого есть позиция по этому вопросу. Даже у меня. Только кому она тут нужна? Не все вопросы решаются системно, не все вопросы решаются. Да и вопросы не всегда вопросы :)
На тот момент, когда оно принималось, были другие условия. Такой подход позволяет обойтись без программаторов транспондеров в пунктах продаж. Транспондеры централизованно прошиваются и распространяются по пунктам продаж, а привязка происходит в момент продажи через CRM путем чтения наклейки со штрих-кодом. Упрощение процесса распространения на начальном этапе — довольно существенный аргумент в пользу этого подхода.
У Автодора транспондеры привязаны к юзеру, а не к машине. Поэтому юзер теоретически может переставлять транспондер из легковушки в грузовик и обратно. Что, соответственно, заставляет каждый раз определять класс, чтобы сформировать правильное списание со счета. Если бы в транспондере был записан класс ТС, то оборудование на портале просто проверяло бы соответствие класса и фактического ТС. В этом случае оси смотреть даже не обязательно, аналитических признаков более чем достаточно. Ну, и выборочные проверки глазами, если паранойя замучила.
Там важный параметр насколько быстро датчик вернется к начальному состоянию. Когда грузовик проносится со скоростью 150 спаренные оси ударят по датчику почти одновременно, он должен их четко различить. Также влияют звуковые и вибрационные волны, асфальт летом мягкий, колеса могут быть приспущены или надуты, могут быть сдвоенными и т.п. Так что народ упражняется по-полной.
Я об этом тоже вскользь упомянул в статье. Насколько я знаю, сейчас проблема поднятых осей пребывает в тумане и решается на уровне белковых компьютеров — операторов в кабинах, которые могут откорректировать класс ТС. В режиме freeflow все усложнится кардинально. Технические решения есть, но это уже какой-то космос, недостойный подобного приземленного применения.
Есть датчики на оптоволокне, регистрирующие изменение геометрии при нажатии. Некоторые даже пытаются на этом делать WIM. Плюсы — монтаж в щель, не нужна бетонная подложка. Минусы — низкая точность, разные параметры по длине (замучаешься калибровать), дорогие ресиверы. Магнитные датчики интереснее, монтируются в дырки, живут долго на батарейках, ресиверы типа bluetooth низкого потребления. Но все это требует влезать в полотно, заботиться о замене, смотреть, чтобы ремонтники не сняли датчики вместе с асфальтом. Проще перестать считать оси или смириться с аналитическими погрешностями в оценке осей по внешнему виду.
Разумеется, можно. Проблема в том, что это: 1. Работает на малых скоростях (применимо только на ПВП) 2. Требует чистки и обслуживания даже больше простых оптических счетчиков. 3. Имеет механическую часть, которая потребует замены с демонтажом и перекрытием движения.
Батарейка обычная литиевая cr-чего-то-там. Держатель впрессован в батарейку. По спецификации Капш ее должно хватать на 7 лет при 2000 проездах в год (как я писал). Другие транспондеры должны иметь схожие параметры. Если транспондер не работает, его должны бесплатно заменить (по идее)
Ну, например Enterprise Architect нет, Aris только в версии Express (java). Ну, понятное дело, Project и Visio. Это только с чем я лично сталкивался пару лет назад во время работы в команде разрабов онолитегом (сейчас уже, может, что изменилось). Сам я код не пишу, поэтому среды разработки не юзаю. А, хотя, стоял у меня Eclipse под Mac за каким-то лешим :)
В общем, основной посыл в том, что иногда нужно потратить много сил, иногда мало. Мак можно заточить под разработку, разумеется. Но именно что заточить.
Активно использую и то и другое, но Слоник не позволяет создавать диаграммы в интерфейсе. В итоге диаграммы отдельно, заметки — отдельно. Я использую диаграммы на этапе сбора информации, интервьюирования и на совещаниях. Потом на базе диаграмм я делаю официальные документы, и их уже храню. Первичная диаграмма бывает нужна довольно редко, хранится в файловой системе.
Юзер Evernote с 2011. Тоже жду окончания платной подписки в январе. У меня в работе основной юскейс создания заметок - веб-клиппер. Переключаемся в режим "Упрощенная страница", выделяем маркером суть, сохраняем. Теги проставляются автоматически. У конкурентов эта фича работает или хуже, или не на всех сайтах. Режим фотографирования документа - еще одна прекрасная фича. Автоматическая обрезка, устранение перспективных искажений, нормализация изображения. Потом даже текст распознается и ищется поиском.
Согласен с автором в том, что развитие Evernote свернуло куда-то не туда. Electron версия на десктопе (вместо прекрасно работавшей нативной), тормозящий мобильный клиент - такое простить сложно. Сейчас я почти перестал пользоваться Evernote как классической системой заметок, стало хватать файловой системы с синхронизацией и поиском, благо в современных ОС поиск стал работать очень неплохо. Но для того, чтобы быстро дернуть страницу в архив, пока использую Слона.
Что до альтернатив, то есть еще такие NAS от Synology, в комплектном софте есть DS Note, который задумывался как аналог Evernote. Есть импорт заметок с облака Evernote (год назад работал, у меня десятки тысяч заметок, все импортировались). Есть десктопное приложение на Electron с локальным кешем в файловой системе, мобильные приложения в сторах (без локального кеша). Есть веб-клиппер по образу Evernote, но не на всех сайтах работает. В целом, со скрипом, буду использовать этот продукт вместо Слона после окончания подписки.
Практикуем смешанный режим работы, с некоторым количеством присутственных дней. Процесс проектирования софта лучше движется, когда есть доступ к физическому телу архитектора/лида. Когда в контексте задачи можно подойти, обсудить что-то, он посмотрит в экран, подтянется кто-то ещё, и вот уже около доски собрался консилиум. Я, как владелец продукта, тут же присоединяюсь к таким тусовкам, чтобы добавлять бизнес-контекст где это необходимо. Подобные мероприятия экономят кучу времени. И я не имею в виду время на дорогу до офиса. Я имею в виду время на выполнение ненужных, не актуальных или некорректно сформулированных задач. Понятно, что можно тратить дополнительные усилия на оформление всего и вся, но в маленьком коллективе это не всегда возможно. И, опять же, куда девать творческую составляющую, когда результат несколько раз может перевернуться с ног на голову и обратно?
Для сравнения, у нас есть иногородние сотрудники, которые физически не могут присутствовать, и с ними приходится пользоваться всеми этими штуками типа видеосвязи и Jira/Confluence. Эффективность подобных коммуникаций заметно ниже, а драйва нет вообще. В общем, лучше иметь возможность работать в офисе, чем не иметь такой возможности. Ну, в нашем случае так точно.
В комментариях вижу боль. Трудно что-то добавить в части эмоций, поэтому досыплю немного наблюдений в части упаковки АСУТП проектов. Не скажу за производство, но, например в дорожной автоматизации проекты оформляются как строительные. ИТ составляющая присутствует одной-двумя строчками в ведомости объемов работ как "АСУ такая-то 1 штука". Разработку стараются запихнуть внутрь пуско-наладочных работ, так как в этих проектах есть только деньги за поставку лицензий, деньги за поставку железа и деньги за работы по наладке и монтажу. Если вы разработчик АСУ и хотите заработать на этой теме, то вам нужно учиться вписываться в эти условия. Как пример, возьмем подход западных людей к снаряду. Когда приходит условный Сименс, у него в цене поставки будут и лицензии, и обязательства по обучению персонала, и сертификация инженеров. К вам бизнес-классом приедет некий чувак для "шеф-монтажа" с запредельным почасовым прайсом. Вам навялят обязательства по приобретению техподдержки за жалкие 30% от цены лицензий. В общем, как в старом бухгалтерском анекдоте про составление авансового отчета за командировку, "шляпа тут, только хрен ты её найдешь".
Представьте теперь, что компания понесла все эти расходы по закупке оборудования, работ и прочего, внесла в бюджет расходы на техподдержку. А на ком теперь экономить? На том самом Васе с покоцаным ноутом, который обслуживает АСУ. Просто все деньги, которые на это были, ушли холеным румынам или словакам в фирменной униформе, а также манагерам в сверкающих офисах класса А. Так устроен мир, собственно.
Подобный перекос он глобальный. Везде самый жирный кусок будут съедать корпорации. Разница лишь в объеме ответственности, который несут корпорации за свой жирный кусок. У нас их ответственность несопоставимо меньше, а условный Вася вынужден брать на себя все косяки и недоделки. Это уже вопросы к качеству юристов и менеджеров. Западные люди очень хорошо видят некомпетентность и умело ей пользуются. В итоге их Вася за свою небольшую зарплату по сути занимается диспетчеризацией заявок и мониторингом. При этом он обучен и защищен сертификатами. А наш Вася в мыле фигачит за тот же прайс. Про рынок тут уже написали много и по делу. Постепенно люди с головой действительно будут вымываться из АСУ, одновременно с деградацией систем и уходом вендоров, что через полгода-год приведет к серьезным отказам и авариям на тех производствах, которые не успеют адаптироваться. Думаю, что кроме, может быть, нефтянки, адаптироваться не успеет никто.
На мой взгляд, нанять в проект сеньора с рынка в принципе нельзя. Можно нанять человека, который на прежней работе считался сеньором, например. И рассчитывать, что в нашем проекте он тоже сможет исполнять функции сеньора. Потому что градации "сеньорности" существуют не вообще, а применительно к конкретному проекту. Перечисленные в статье навыки, безусловно, способствуют этому и увеличивают вероятность занять сеньорскую позицию на большинстве проектов.
Как правильно писали некоторые комментаторы, существуют проекты и сеньоры на них, которым не нужны многие перечисленные навыки. Мне кажется, количество навыков - это не про конкретный проект, а про легкость перехода на другой проект.
Я не разработчик, а владелец продуктов, и для меня сеньор-разработчик это в первую очередь технологический партнер, ведущий инженер и проводник в мир разработки в рамках своего продукта или части продукта. "Сеньорность" определяется для меня двумя параметрами:
Насколько свободно человек может объясняться на понятном мне языке и выступать инструментом управления ходом разработки в части принятия правильных технических решений. Не лезть в них, а именно помогать команде принимать правильные решения путем трансляции нюансов из мира бизнеса. Чтобы пилить нужные фичи, выбирать нужные направления на развилках. На мой взгляд, сеньор это мидл, который умеет говорить понятно для бизнеса о том, чем занимается команда.
Сколько лишней работы позволил "не делать" опыт этого человека. В маленькой команде на большом проекте любой вариант что-то не делать на вес золотом. Технический кругозор сеньора дает возможность применять готовые решения, методики, фреймворки, не изобретать велосипеды там, где это возможно. Это еще одно ключевое отличие от мидла, который тоже офигенно хороший спец, но который комфортно живет в своем пузыре. Я очень люблю мидлов, они делают всю работу на самом деле. Но это их ограничение может дорого обойтись компании. Сеньор - это тот человек, который может залезть на самое высокое дерево и осмотреть окрестности.
Тут поминали некоего "архитектора" в комментариях. Для меня ИТ-архитектор - это всё же роль, а не человек. Что-то типа бизнес-аналитика, который специализируется на выявлении нефункциональных требований и планирует их реализацию. В маленьких компаниях роль архитектора берет на себя обычно сеньор по направлению в те моменты, когда это необходимо. Он же разруливает архитектурные вопросы в ходе проектирования, если они возникают.
— На изображении ТС должен быть виден номерной знак, модель ТС (можно без цвета)
— На изображении должен стоять штамп с датой, временем, идентификатором камеры (отметкой места съемки)
— Камера (с ПО) должна иметь сертификат СИ и поверку как минимум по времени (чтобы нельзя было оспорить время правонарушения). Также можно получить сертификат СИ на координаты — тогда нельзя будет оспорить и место съемки, и в суде будет «железная» тройка — фото ТС, время и место.
— Должна быть исключена модификация собранных данных кем бы то ни было. Т.е., у суда должна быть уверенность, что данные поступили в автоматическом режиме, а не из фотошопа. Технически корпус камеры должен быть опечатан, фотоматериалы должны иметь ЭЦП по ГОСТу (просто ЭЦП не считается)
При этом любая аналитическая обработка, типа распознавания ГРЗ, классификации и т.п., не является доказательством в суде. Это только для удобства поиска и формирования материалов.
Схема 1 сейчас доминирует. На уровне бизнес-процессов возникают существенные нюансы. Например, в случае пиковых нагрузок при схеме 1 оператор не будет открывать шлагбаумы, так как его KPI — уровень собираемости, который жестко контролируется «владельцем». По схеме 2 оператору проще пропустить людей на дорогу бесплатно, лишь бы не вызывать негатив, так как его KPI — общее количество собранных средств. Отсюда и разные подходы к управлению. При схеме 1 оператор будет держать персонал и обеспечивать отказоустойчивость, чтобы соблюсти KPI по доступности сервиса. По схеме 2 оператор будет экономить средства и принимать риски по отказу оборудования и систем с целью уменьшить OPEX. Время покажет, какая схема эффективнее, но пока судить рано.
Дмитрий, прежде чем повышать самооценку за чужой счет, внимательно читайте статью и комментарии к ней.
В общем, основной посыл в том, что иногда нужно потратить много сил, иногда мало. Мак можно заточить под разработку, разумеется. Но именно что заточить.