по-моему, очевидно, что счетчик помимо подключения к электросети просто имеет обычный сетевой модуль, будучи подключенным дополнительно к интернет каналу, сигнал которого передается по обычному телевизионному коаксиальному кабелю, и соотв. MAC-адрес, ну и так далее. Ничего особенного вообщем. Ваш же случай, конечно, да, тяжелый:)
лейбл на счетчике от компании, которая электричество поставляет — Fortum, а сам счетчик вероятно OEM-овский от какого-нибудь китайского производителя (могу посмотреть конечно, что там еще на нем написано).
Ну и ахтунг! Мой счетчик сразу к интернету подключен и я смотрю все характеристики в режиме рального времени, плюс всю статистику за последние полгода-год. В России последние лет 5-6 внедряются такие счетчики, знаю целую контору, развивающую такой бизнес.
Жить можно. При постоянном проживании за границей, регистрация в ближайшем консульском учреждении (при условии, естественно, полной выписки из России соотв.) делает из вас «нерезидента» с точки зрения российского законодательства официально. Для меня лично в свое время (лет 6 назад) это значительно облегчило поездки в Россию на личном авто с иностранными регистрационными номерами из сопредельного государства, так сказать. Плюс обмен загранпаспорта по почте и за месяц (сейчас уже такая лафа не действует).
А если жить заграницей и держать прописку в России — ну тогда как минимум какие-то копейки за квартплату надо будет платить.
Были года в молодости, когда за месяц ( при норме где-то в 160 часов) набегало 260, а то и больше. Пахал как краб на галерах. Проект интересный, за окном холодный ноябрь, дома никто не ждет, да и любимое дело в удовольствие — вот работа и захватывала с головой (разработка софта). Думал, что может меня интересовать больше, чем новые технологии и искусство программирования…
Сейчас двое детей, ждем третьего ребенка, куплен дом с участком в 10 соток… теперь я с газонокосилкой, дрелью, кистью, в гараже, в детском саду, поликлинике… жизнь заставила оторваться от офисного кресла. Впрочем не жалею.
Я в свое время менял загранпаспорт в консульском отделе посольства России в Финляндии. Скачал с их сайта анкеты, заполнил, распечатал, приложил фотографии, текущий загранпаспорт и отправил письмом им. Через три недели позвонил и поторопил, чтобы быстрее делали:) и буквально через пару дней получил заказным письмом новый паспорт (старый тоже вернули с вырезанным серийником, так как там визы). Оплатил пошлину на почте при получении.
Вот была радость то не мотаться в Хельсинки, не стоять в очередях, не тратить время и деньги. Правда давно уже прикрыли эту многолетнюю практику обмена по почте, так как не совсем законная схема была… ужесточили процедуру.
У меня W500 уже два года. Ох и намучался я с этими дискретными картами… куча глюков, при дополнительном подключенном мониторе блюскрин почти каждый день в течение почти года пока не выпустили обновление драйверов.
Но несмотря на все проблемы, очень качественный экран, матовый, разрешение 1920 1200, глаза совершенно не устают. Смотреть не могу на глянцевые самсунги и асеры после этого экрана.
Пытался купить билет. Регистрация, поиск, заполнение данных — все просто и интуитивно. А сторонний обработчик транзакций через транскредитбанк — полный отстой. Ни одну из моих карточек (Mastercard Silver, Visa Classic, Visa electron), которыми я уже лет 5 где только можно расплачивался — не приняла система… Карточки правда все — из финских банков.
Такая огромная организация — РЖД — и такое качество сервиса. Мой товарищ тоже жаловался, что его кредитки финские то работают, то не работают.
Я очень разочарован данным сервисом. Хотели как лучше, а получилось как всегда. Несерьезно для таких масштабов, как у РЖД… да и вообще просто несерьезно…
В Финляндии я вообще уже забыл, как выглядят наличные деньги и дорогу в банк. А все билеты на местные поезда покупаются в интернете, а билет приходит СМСкой на телефон, которую показываешь проводнику, если лень распечатать бумажку на принтере.
Вы совершенно правы. Согласен со всем сказанным.
А мой пост немного скомкан. Просто захотелось отписаться по такой животрепещущей теме, где столько копий сломано было, а когда начал писать, понял, что в двух словах пятилетний опыт не отразить.
Нюансов очень много и человеческий фактор безусловно важен. Попытки сконцентрироваться лишь на одном или нескольких аспектах той или иной методологии — часто не только не достигают поставленных целей, но могут перечеркнуть вообще все вообщем-то хорошие начинания. В нашем случае — слишком сильная зацикленность на time estimation, schedule tracking. Это тоже важно, безусловно. Но опять же, то, как все было организовано — в том числе и из-за недостатка опыта, нехватки времени изучить вопрос и получить этот самый опыт — привело к непониманию среди разработчиков. Процесс (Scrum) в таком виде просто не сработал у нас и бы на время предан забвению даже.
А когда вообще без какого-либо обсуждения пытаются внедрять что то сверху (как видимо в вашем случае) — это не способствует пониманию в команде. Я думаю любая методология следующая каким-угодно state-of-the-art принципам в условиях небольшой компании или команды нуждается в притирке к нуждам этой компании и с учетом человеческого фактора. В каждой компании есть свои устоявшиеся правила (будь то форматирование кода или использование каких-то «тулзов»). Приходит новый менеджер из другой маленькой компании и пытается насадить свой «опыт». Этот опыт не обязательно приживется в вашей компании и не обязательно подходит именно для «вас». Вообщем с такими «разнарядками» я был бы осторожен. Сначала нужно все обсудить и вместе искать нове решения.
Читаю и узнаю все те типичные ошибки и проблемы, через которые прошла моя компания внедрив Scrum года два с половиной назад еще… Только вместо JIRA мы используем Mantis — bug tracking system. Опыт одного проекта, который изначально планировался месяцев на 6-8, а вылилось все в почти что двухлетнюю доводку до ума (большая GIS информационная система для государственной организации, занимающейся управлением лесной гос. и частной собственностью) показал, что надо что то срочно делать. Пришел менеджер, принес распечатку статьи страниц на 5 про Scrum: «Будем внедрять».
Во что все вылилось? Спринты двухнедельные. Каждая задача в Мантисе получала предварительную оценку по-времени. Сидели на митинге часа по два-три, обсуждали задачи в порядке очередности, на ходу планировали, изменяли, дизайнили, каждый разработчик оценивал свои задачи. На следующем митинге задачи, которые не успели сделать перекидывали в новый спринт и так далее. Иногда читалось какое-то молчаливое недоумение в глазах девелоперов… Редко когда удавалось уложиться в расписание. Потому что на коленке нельзя проводить даже грубую оценку — it just fails. Как показывает опыт, время на изучение — initial research, анализ и планирование реализации задачи, тестирование, ну вообщем многие аспекты, напрямую не связанные с написанием кода, не учитываются при оценке, данной разработчиком. Для этого нужен опыт, а также соответствующее звено между менеджментом (по работе с заказчиками) и инженерами — технический менеджмент — который в нашей небольшой компании (lack of resources — typical problem) заменялось общими усилиями всех и вся: и ПМ, работающих с заказчиками, и девелоперами. А также знания, хотя бы теоретические (с тех пор прочитал много полезных и интересных книг по Скраму), а не статья на пять страниц.
Короче менеджеры уходят, приходят, а мы на ошибках учимся. Один из выводов, к которому я пришел уже очень давно по поводу описанного проекта и подохода к управлению — неправильное использование «тулзов» — в нашем случае Mantis — что есть изначально и прежде всего всего лишь bug tracking system. Помню — сидишь и напрягаешься, а сколько же в этот раз дней поставить — time estimation. А сроки поджимают — дела надо делать: разрабтаывать, тестировать, баги править…
Вообщем кратко: компания небольшая, все сами себе и архитекторы, и разработчики, и тестеры, и планировщики (в последнее время порядок кое как наводится в этом отношении). Недостаток ресурсов (human resources) привел к тому, что менеджер по работе с заказчиками, взялся за управление процессом разработки с точки зрения трудозатрат и так далее. От этого — неправильное использование «тулзов», расточительное изпользование времени на митинги перед спринтами для обсуждения и оценки времени. А отсюда внутреннее непонимание у разработчиков, которое очень мешало сосредоточиться на полезной работе. И как итог, я считаю, что мы могли потратить намного меньше времени на проект, если бы… ну а это уже совсем другая история, возможно даже статью напишу, где проанализирую наши ошибки. Благо опыт самый разнообразный, с разными менеджерами и разными проектами.
Оценку надо проводить безусловно. Прежде всего даже — для себя. Это мобилизует, стимулирует к улучшению различных профессиональных навыков. Самоорганизует. Хочется совершенствоваться, расширять знания, умения. В том числе и в области управления чем-то большим, чем разработка yet another cool widget. Это ведь целая проблемная область, над которой бьются во многих больших IT корпорациях. И считаю — что начинать нужно с себя. Тогда никакие менеджеры не страшны.
Сорри, что много, наверное лучше будет статейку даже накатать.
А если жить заграницей и держать прописку в России — ну тогда как минимум какие-то копейки за квартплату надо будет платить.
Сейчас двое детей, ждем третьего ребенка, куплен дом с участком в 10 соток… теперь я с газонокосилкой, дрелью, кистью, в гараже, в детском саду, поликлинике… жизнь заставила оторваться от офисного кресла. Впрочем не жалею.
Вот была радость то не мотаться в Хельсинки, не стоять в очередях, не тратить время и деньги. Правда давно уже прикрыли эту многолетнюю практику обмена по почте, так как не совсем законная схема была… ужесточили процедуру.
Но несмотря на все проблемы, очень качественный экран, матовый, разрешение 1920 1200, глаза совершенно не устают. Смотреть не могу на глянцевые самсунги и асеры после этого экрана.
Такая огромная организация — РЖД — и такое качество сервиса. Мой товарищ тоже жаловался, что его кредитки финские то работают, то не работают.
Я очень разочарован данным сервисом. Хотели как лучше, а получилось как всегда. Несерьезно для таких масштабов, как у РЖД… да и вообще просто несерьезно…
В Финляндии я вообще уже забыл, как выглядят наличные деньги и дорогу в банк. А все билеты на местные поезда покупаются в интернете, а билет приходит СМСкой на телефон, которую показываешь проводнику, если лень распечатать бумажку на принтере.
А мой пост немного скомкан. Просто захотелось отписаться по такой животрепещущей теме, где столько копий сломано было, а когда начал писать, понял, что в двух словах пятилетний опыт не отразить.
Нюансов очень много и человеческий фактор безусловно важен. Попытки сконцентрироваться лишь на одном или нескольких аспектах той или иной методологии — часто не только не достигают поставленных целей, но могут перечеркнуть вообще все вообщем-то хорошие начинания. В нашем случае — слишком сильная зацикленность на time estimation, schedule tracking. Это тоже важно, безусловно. Но опять же, то, как все было организовано — в том числе и из-за недостатка опыта, нехватки времени изучить вопрос и получить этот самый опыт — привело к непониманию среди разработчиков. Процесс (Scrum) в таком виде просто не сработал у нас и бы на время предан забвению даже.
А когда вообще без какого-либо обсуждения пытаются внедрять что то сверху (как видимо в вашем случае) — это не способствует пониманию в команде. Я думаю любая методология следующая каким-угодно state-of-the-art принципам в условиях небольшой компании или команды нуждается в притирке к нуждам этой компании и с учетом человеческого фактора. В каждой компании есть свои устоявшиеся правила (будь то форматирование кода или использование каких-то «тулзов»). Приходит новый менеджер из другой маленькой компании и пытается насадить свой «опыт». Этот опыт не обязательно приживется в вашей компании и не обязательно подходит именно для «вас». Вообщем с такими «разнарядками» я был бы осторожен. Сначала нужно все обсудить и вместе искать нове решения.
Во что все вылилось? Спринты двухнедельные. Каждая задача в Мантисе получала предварительную оценку по-времени. Сидели на митинге часа по два-три, обсуждали задачи в порядке очередности, на ходу планировали, изменяли, дизайнили, каждый разработчик оценивал свои задачи. На следующем митинге задачи, которые не успели сделать перекидывали в новый спринт и так далее. Иногда читалось какое-то молчаливое недоумение в глазах девелоперов… Редко когда удавалось уложиться в расписание. Потому что на коленке нельзя проводить даже грубую оценку — it just fails. Как показывает опыт, время на изучение — initial research, анализ и планирование реализации задачи, тестирование, ну вообщем многие аспекты, напрямую не связанные с написанием кода, не учитываются при оценке, данной разработчиком. Для этого нужен опыт, а также соответствующее звено между менеджментом (по работе с заказчиками) и инженерами — технический менеджмент — который в нашей небольшой компании (lack of resources — typical problem) заменялось общими усилиями всех и вся: и ПМ, работающих с заказчиками, и девелоперами. А также знания, хотя бы теоретические (с тех пор прочитал много полезных и интересных книг по Скраму), а не статья на пять страниц.
Короче менеджеры уходят, приходят, а мы на ошибках учимся. Один из выводов, к которому я пришел уже очень давно по поводу описанного проекта и подохода к управлению — неправильное использование «тулзов» — в нашем случае Mantis — что есть изначально и прежде всего всего лишь bug tracking system. Помню — сидишь и напрягаешься, а сколько же в этот раз дней поставить — time estimation. А сроки поджимают — дела надо делать: разрабтаывать, тестировать, баги править…
Вообщем кратко: компания небольшая, все сами себе и архитекторы, и разработчики, и тестеры, и планировщики (в последнее время порядок кое как наводится в этом отношении). Недостаток ресурсов (human resources) привел к тому, что менеджер по работе с заказчиками, взялся за управление процессом разработки с точки зрения трудозатрат и так далее. От этого — неправильное использование «тулзов», расточительное изпользование времени на митинги перед спринтами для обсуждения и оценки времени. А отсюда внутреннее непонимание у разработчиков, которое очень мешало сосредоточиться на полезной работе. И как итог, я считаю, что мы могли потратить намного меньше времени на проект, если бы… ну а это уже совсем другая история, возможно даже статью напишу, где проанализирую наши ошибки. Благо опыт самый разнообразный, с разными менеджерами и разными проектами.
Оценку надо проводить безусловно. Прежде всего даже — для себя. Это мобилизует, стимулирует к улучшению различных профессиональных навыков. Самоорганизует. Хочется совершенствоваться, расширять знания, умения. В том числе и в области управления чем-то большим, чем разработка yet another cool widget. Это ведь целая проблемная область, над которой бьются во многих больших IT корпорациях. И считаю — что начинать нужно с себя. Тогда никакие менеджеры не страшны.
Сорри, что много, наверное лучше будет статейку даже накатать.