Такая система была не только в майкрософте. Вообще модная была тенденция. Сейчас от такого везде отказываются.
Сомневаюсь насчет протаскивания идиотов. Если у менеджера есть команда, то эти проценты он считает для своих людей, сам же оценивается у вышестоящего руководителя, у которого уже свои проценты. От того, что в команде менеджера идиоты — может пострадать только он сам — потому что команда будет неэффективна и руководитель этого менеджера добавит его в плохие проценты.
Проблема мне кажется тут прежде всего в негативном влиянии на мотивацию. Система очень негибкая. На самом деле бывает так, что нет каких то «героев» — тогда поощрение псевдогероев выглядит неуместно. Так же как и не всегда бывают «отстающие». Осознание того, что даже если ты работаешь очень хорошо, но чуть хуже чем остальные, тебя могут наказать — довольно тяжкое бремя.
Сокращают отделы или как минимум команды. А не отдельных людей. И решения такие принимаются на таком уровне, на котором на компетенцию отдельных людей внимания не обращают.
Тебе скорее скорее всего подыщут другое место, если ты звезда такого уровня, что тебя знают на самом верху — но таких сотрудников единицы даже в майкрософте.
Обычно просто предлагают найти работу внутри если захочешь (и остаться без компенсационного пакета). И успех этого мероприятия будет зависеть не от того, насколько ты хорош, а есть ли вакансия, соответствующая твоей компетенции (с твоим уровнем зарплаты и карьерных ожиданий).
Хорошим специалистам найти работу не проще чем плохим — потому что ожидания у них тоже куда выше.
Отсутствие АСЦ — ок. Хотя сервисные центры крупнейших производителей лептопов (эпл, леново, асер, асус и т.п. есть по моему в любом крупном городе).
Что касается того, где было куплено — им должно быть по барабану совершенно. Нужно просто зайти на сайт производителя и убедится что конкретно твой лептоп там зарегистрирован и гарантия включилась. Я вообще у какого то барыги на ебее покупал себе лептоп — уцененный к тому же — никаких проблем с гарантией не было. На сайте производителя все правильно было зарегано — в сервисном центре приняли. При этом никакого магазина не было и в помине, как и каких либо гарантийных бумажек.
Ну представьте себе — что вы топ менеджер в компании — который отвечает за разработку решения, позволяющего отлаживать юнити в студии. Необходимость этого решения даже обсуждать смысла нет. Вы посчитали, что разработка будет стоить 2N денег и P времени, а покупка компании которая его уже разработала (то есть самого продукта, и команды, которая его будет поддерживать) стоит N денег и 0 времени. Вы выбрали второй вариант.
Вполне разумное решение — при чем тут попил бюджета.
Скажите какие там форматы поддерживаются — там вместо списка форматов иконки — не пойму что они значат (кроме pdf конечно который не особенно интересен).
Ок — а зачем проверять, что файл был действительно удален. Вашего уровня доверия базовым библиотекам недостаточно для того, чтобы быть уверенным в том, что если вы говорите им «удали файл» — то библиотека будет себя вести в соответствии со спецификацией?
Ведь создатели библиотеки уже потратили деньги на ее тестирование.
Мне кажется вы не совсем понимаете сути. Ваш код — это ваш написанный код. Все что не ваш код — это не ваш код. Его не нужно проверять если речь идет о модульных тестах.
То поток выполнения кода не должен выходить за пределы вашего кода. Внешним интерфейсом, поведение которого вы проверяете будет сигнатура ваших методов (сигнатура метода, вызываемого из финализатора например) и все точки вызовов внешних библиотек (моки). Используя язык моков вы и последовательность внешних вызовов можете проверить и то, с какими параметрами они вызываются.
Тестировать приватные методы (которые внутри финализатора вызываются) не проблема совершенно. Мокать статические классы базовых библиотек — тоже не большая проблема — для этого есть специальные инструменты. Можно обойтись даже без своих оберток.
Тестировать то, что отрабатывает собственно финализатор и к чему это приводит нужно совсем другими тестами и в рамках другой деятельности (системное тестирование приложения как черного ящика).
Не понимаю, почему вы это называете словами «как проверить код финализатора»??
Вы помимо кода финализатора хотите проверить:
1) Механизм виртуальной машины который вызывает финализатор (не доверяете майкрософту? думаете они это не тестируют?).
2) Механизм базовых библиотек которые удаляют файлы (тоже какое то неадекватное недоверие).
Если хотите проверить работоспособность своего кода, который содержит значимый бизнес, а не вызов Dispose, то думаю вы без проблем сумеете его вызвать.
По факту вы хотите воссоздать какое то окружение, близкое к реальной ситуации и проверить не свой код, а его связку с базовыми механизмами — вас спасут системные тесты на весь продукт в целом. Интеграционный тест на такую ситуацию написать трудно — да и смысла в этом нет — все равно это будет не то же самое, что в реальном окружении.
В общем простите — но по моему вы ерундой какой то занимаетесь. Правда — трудно поверить что такой тест может иметь смысл.
Ну модульные тесты всегда дают что то взамен. Но вопрос окупаемости у них действительно стоит остро.
Что касается того, что программисты перестают думать — они могут просто думать на более высоких уровнях абстракции вот и все. Классическое тестирование изолированного метода или функции например — каждому программисту будет всегда казаться, что он может смоделировать в уме ее поведение. Но по факту это не так. Он наверняка ошибется. И сам этого не заметит. Заметит пользователь, который поймает багу. Сложные системы — это сложные системы. В их разработке полагаются прежде всего на практики и методологии, а не на ум отдельных разработчиков (ну в этом контексте разговора конечно — аджайл манифест мы помним).
TDD вообще не так уж часто используют на самом деле. И есть огромное количество людей — которые их боятся применять — потому что не умеют или умеют неправильно. По моему перестать пропагандировать TDD когда нибудь надо будет — но пока еще рано. Попытки его использования позволяют пересмотреть архитектуру, выделить значимую логику, походящую для тестирования и избавиться от незначимой (разные бесполезные маппинги и слои). Пусть это побудет еще немного священным граалем. В моей практике TDD может быть невероятно выгодным. И стоимоть поддержки тестов может окупиться с лихвой. И скорость разработки с TDD через модульные тесты может быть выше чем вообще без тестов — как это парадоксально не звучит.
Во первых TDD и юнит тесты — это все таки не одно и тоже. А автор связал тесно эти два понятия. Например идея написания спецификаций для системных тестов к планнингу перед написанием кода — это по большому счету тоже TDD.
У автора проблемы с модульными тестами по моему. Модульные тесты без TDD вообще редко окупаются на проекте на мой взгляд. С TDD они работают отлично. Но у них есть своя область применения. В первых они требуют архитектурной готовности системы, что усложняет дело для унаследованного кода. Во вторых они выгодны для тестирования своей бизнес логики. В реальности в большинстве проектов своей логики не так уж и много. В основном это разные маппинги и слои для работы с внешними сервисами — которые полезной логики практически не содержат и в покрытие их модульными тестами в изолированном окружении кажется не очень выгодным.
Мне кажется именно в эту ситуацию автор и попал. Со стороны же статья выглядит как «ок — у меня не выходит использовать TDD — поэтому я буду проповедовать, что это зло».
TDD вовсе не мертво и работает. Просто нужно его уметь правильно готовить и выбирать область применимости.
Я сразу уточню, что говорю о полной интеграции (комментарии и т.п.)
Ну вы как разработчик сайта кого выберете — фейсбук или гугл плюс для интеграции? По моему ответ очевиден несмотря на полмиллиарда активных пользователей гугл плюса.
Про аппеляци. к аудитории — я имел ввиду сегодняшнюю аудитории. Вот прямо сейчас делать ставку на интеграции с гугл плюс не выгодно. Как и 2 года назад. Как не выгодно и с вконтакте например (если мир в целом). Аудитории недостаточно, хоть ее и много. Но она очень быстро растет. Даже сейчас. Если такой темп продолжиться гугл плюс может достигнуть скажем 50-70% от фейсбука — это может быть переломным моментом.
Что касается логина через гугл плюс — то его не бывает насколько я понимаю. Есть логин через гугл — который включает гугл плюс. И он есть очень много где.
Статистику не видел — не в курсе насколько он популярнее или непопулярнее чем фейсбук и твиттер. Но из тех приложений, которыми я пользуюсь это например Flickr, Хабр, Pocket. В целом выглядит как будто через фейсбук логинов побольше. Но бывает что есть только чрез гугл. Но это опять же личный опыт. Можно изучить эту тему детальнее.
У гугла помимо соцсети есть еще другие сервисы для интеграции — календарь, карты и т.п. И соцсеть тут как бы удобно ложиться автоматически. Конечно они и этот ресурс заиспользуют по полной.
Да — вы правы в каком то смысле это так и есть. Я бы сказал, что гугл плюс использует по максимуму мощь своих сервисов для продвижения своей социальной сети. Что логично. И пока что они менее успешны, чем фейсбук в интеграции во внешние сервисы.
Но они идут ровно по тому же пути. У них есть возможности интеграции с любыми сайтами. Ондако для внешних сайтов фейсбук предпочтительнее на данный момент — так как больше аудитория. Практически использование своего внутреннего ресурса — единственный шанс вырасти до уровня фейсбука в интеграции тем самым сделав интеграцию с гугл плюсом для внешних сайтов оправданной.
Так что гугл плюс и фейсбук движутся в будущее используя немного разные подходы в рамках своей ситуации всего навсего.
И то, что гугл плюс тут проиграл для меня пока что совершенно не очевидно.
Приведенные выше цифры не о том, сколько человек зарегистрировалось. А о том, кто активно пользуется сервисом через их сайт или другие сайты.
Интеграция с другими сервисами и есть основной тренд социальных сетей — их будущее и уже настоящее. То насколько они интегрированы в популярные сервисы тоже определяет их успех.
Слово пузырь сегодня очень популярно да — но ни к фейсбуку, ни к гугл плюсу в контексте разговора по крайней мере это отношения не имеет.
Показатели успешности социальных сетей конечно стоит правильно интерпретировать — но это именно показатели успешности соцсетей. А не какие то там счетчики регистраций.
Я говорю не о то, правы вы или нет. А о том, что свои слова нужно подтверждать. О качестве статьи в целом.
Не знаю насчет того, что дутое, а что нет. Есть официальные отсчеты на эту тему. Фейсбуку еще выгоднее раздувать свои рузультаты — у них тоже есть акционеры — и это основа их бизнеса, в отличие от Гугла. Если вы сами не занимаетесь исследованиями активности пользователей — то нужно опираться на источники, а не на то, что «мои друзья не пользуются гугл плюсом».
Что касается вашей правоты. Рост активности фейсбука почти стагнирующий. Рост активности гугл плюс огромный — и стабильный (они не сразу получили свои полмиллиарда) — и о падении скорости роста пока говорить не приходиться. Их размер уже сопоставим и гугл плюс впереди всех конкурентов фейсбука.
Ну как можно говорить, о том, что гугл плюс сдулся? Не сдулся он — а раздувается бешеными темпами.
А уж через какой интерфейс это происходит (ютуб и т.п.) — вопрос не такой уж важный. Фейсбук наращивает активность используя интеграцию кнопки лайк на все сайты. Многие просто лайкают и на фейсбук ленту даже не смотрят. Гугл плюс — делает ставку помимо этого на ютуб. Суть соцсети вовсе не в том, чтобы «сидеть на сайте фейсбука или гугл плюса», а в том, чтобы использовать их сервисы, чтобы делиться информацией.
Я бы сказал, что статья вообще — голословные утверждения.
Мысли конечно интересные, но заявления вроде «И тем не менее Google+ — это провал. » не мешало бы подкрепить ссылками и исследованиями, а не только какими то там размышлялками.
Чтобы судить об успехе гугл+ нужно 1) обозначить какие он перед собой ставил цели; 2) выяснить насколько они были достигнуты.
Сомневаюсь насчет протаскивания идиотов. Если у менеджера есть команда, то эти проценты он считает для своих людей, сам же оценивается у вышестоящего руководителя, у которого уже свои проценты. От того, что в команде менеджера идиоты — может пострадать только он сам — потому что команда будет неэффективна и руководитель этого менеджера добавит его в плохие проценты.
Проблема мне кажется тут прежде всего в негативном влиянии на мотивацию. Система очень негибкая. На самом деле бывает так, что нет каких то «героев» — тогда поощрение псевдогероев выглядит неуместно. Так же как и не всегда бывают «отстающие». Осознание того, что даже если ты работаешь очень хорошо, но чуть хуже чем остальные, тебя могут наказать — довольно тяжкое бремя.
Тебе скорее скорее всего подыщут другое место, если ты звезда такого уровня, что тебя знают на самом верху — но таких сотрудников единицы даже в майкрософте.
Обычно просто предлагают найти работу внутри если захочешь (и остаться без компенсационного пакета). И успех этого мероприятия будет зависеть не от того, насколько ты хорош, а есть ли вакансия, соответствующая твоей компетенции (с твоим уровнем зарплаты и карьерных ожиданий).
Хорошим специалистам найти работу не проще чем плохим — потому что ожидания у них тоже куда выше.
Что касается того, где было куплено — им должно быть по барабану совершенно. Нужно просто зайти на сайт производителя и убедится что конкретно твой лептоп там зарегистрирован и гарантия включилась. Я вообще у какого то барыги на ебее покупал себе лептоп — уцененный к тому же — никаких проблем с гарантией не было. На сайте производителя все правильно было зарегано — в сервисном центре приняли. При этом никакого магазина не было и в помине, как и каких либо гарантийных бумажек.
AVOID!!! AVOID!!! AVOID!!! BAD FOOD!!! AVOID!!! AVOID!!! RUN AWAY!!!
Вполне разумное решение — при чем тут попил бюджета.
Ведь создатели библиотеки уже потратили деньги на ее тестирование.
То поток выполнения кода не должен выходить за пределы вашего кода. Внешним интерфейсом, поведение которого вы проверяете будет сигнатура ваших методов (сигнатура метода, вызываемого из финализатора например) и все точки вызовов внешних библиотек (моки). Используя язык моков вы и последовательность внешних вызовов можете проверить и то, с какими параметрами они вызываются.
Тестировать приватные методы (которые внутри финализатора вызываются) не проблема совершенно. Мокать статические классы базовых библиотек — тоже не большая проблема — для этого есть специальные инструменты. Можно обойтись даже без своих оберток.
Тестировать то, что отрабатывает собственно финализатор и к чему это приводит нужно совсем другими тестами и в рамках другой деятельности (системное тестирование приложения как черного ящика).
Вы помимо кода финализатора хотите проверить:
1) Механизм виртуальной машины который вызывает финализатор (не доверяете майкрософту? думаете они это не тестируют?).
2) Механизм базовых библиотек которые удаляют файлы (тоже какое то неадекватное недоверие).
Если хотите проверить работоспособность своего кода, который содержит значимый бизнес, а не вызов Dispose, то думаю вы без проблем сумеете его вызвать.
По факту вы хотите воссоздать какое то окружение, близкое к реальной ситуации и проверить не свой код, а его связку с базовыми механизмами — вас спасут системные тесты на весь продукт в целом. Интеграционный тест на такую ситуацию написать трудно — да и смысла в этом нет — все равно это будет не то же самое, что в реальном окружении.
В общем простите — но по моему вы ерундой какой то занимаетесь. Правда — трудно поверить что такой тест может иметь смысл.
Что касается того, что программисты перестают думать — они могут просто думать на более высоких уровнях абстракции вот и все. Классическое тестирование изолированного метода или функции например — каждому программисту будет всегда казаться, что он может смоделировать в уме ее поведение. Но по факту это не так. Он наверняка ошибется. И сам этого не заметит. Заметит пользователь, который поймает багу. Сложные системы — это сложные системы. В их разработке полагаются прежде всего на практики и методологии, а не на ум отдельных разработчиков (ну в этом контексте разговора конечно — аджайл манифест мы помним).
TDD вообще не так уж часто используют на самом деле. И есть огромное количество людей — которые их боятся применять — потому что не умеют или умеют неправильно. По моему перестать пропагандировать TDD когда нибудь надо будет — но пока еще рано. Попытки его использования позволяют пересмотреть архитектуру, выделить значимую логику, походящую для тестирования и избавиться от незначимой (разные бесполезные маппинги и слои). Пусть это побудет еще немного священным граалем. В моей практике TDD может быть невероятно выгодным. И стоимоть поддержки тестов может окупиться с лихвой. И скорость разработки с TDD через модульные тесты может быть выше чем вообще без тестов — как это парадоксально не звучит.
У автора проблемы с модульными тестами по моему. Модульные тесты без TDD вообще редко окупаются на проекте на мой взгляд. С TDD они работают отлично. Но у них есть своя область применения. В первых они требуют архитектурной готовности системы, что усложняет дело для унаследованного кода. Во вторых они выгодны для тестирования своей бизнес логики. В реальности в большинстве проектов своей логики не так уж и много. В основном это разные маппинги и слои для работы с внешними сервисами — которые полезной логики практически не содержат и в покрытие их модульными тестами в изолированном окружении кажется не очень выгодным.
Мне кажется именно в эту ситуацию автор и попал. Со стороны же статья выглядит как «ок — у меня не выходит использовать TDD — поэтому я буду проповедовать, что это зло».
TDD вовсе не мертво и работает. Просто нужно его уметь правильно готовить и выбирать область применимости.
Ну вы как разработчик сайта кого выберете — фейсбук или гугл плюс для интеграции? По моему ответ очевиден несмотря на полмиллиарда активных пользователей гугл плюса.
Про аппеляци. к аудитории — я имел ввиду сегодняшнюю аудитории. Вот прямо сейчас делать ставку на интеграции с гугл плюс не выгодно. Как и 2 года назад. Как не выгодно и с вконтакте например (если мир в целом). Аудитории недостаточно, хоть ее и много. Но она очень быстро растет. Даже сейчас. Если такой темп продолжиться гугл плюс может достигнуть скажем 50-70% от фейсбука — это может быть переломным моментом.
Что касается логина через гугл плюс — то его не бывает насколько я понимаю. Есть логин через гугл — который включает гугл плюс. И он есть очень много где.
Статистику не видел — не в курсе насколько он популярнее или непопулярнее чем фейсбук и твиттер. Но из тех приложений, которыми я пользуюсь это например Flickr, Хабр, Pocket. В целом выглядит как будто через фейсбук логинов побольше. Но бывает что есть только чрез гугл. Но это опять же личный опыт. Можно изучить эту тему детальнее.
У гугла помимо соцсети есть еще другие сервисы для интеграции — календарь, карты и т.п. И соцсеть тут как бы удобно ложиться автоматически. Конечно они и этот ресурс заиспользуют по полной.
Но они идут ровно по тому же пути. У них есть возможности интеграции с любыми сайтами. Ондако для внешних сайтов фейсбук предпочтительнее на данный момент — так как больше аудитория. Практически использование своего внутреннего ресурса — единственный шанс вырасти до уровня фейсбука в интеграции тем самым сделав интеграцию с гугл плюсом для внешних сайтов оправданной.
Так что гугл плюс и фейсбук движутся в будущее используя немного разные подходы в рамках своей ситуации всего навсего.
И то, что гугл плюс тут проиграл для меня пока что совершенно не очевидно.
Интеграция с другими сервисами и есть основной тренд социальных сетей — их будущее и уже настоящее. То насколько они интегрированы в популярные сервисы тоже определяет их успех.
Слово пузырь сегодня очень популярно да — но ни к фейсбуку, ни к гугл плюсу в контексте разговора по крайней мере это отношения не имеет.
Показатели успешности социальных сетей конечно стоит правильно интерпретировать — но это именно показатели успешности соцсетей. А не какие то там счетчики регистраций.
Не знаю насчет того, что дутое, а что нет. Есть официальные отсчеты на эту тему. Фейсбуку еще выгоднее раздувать свои рузультаты — у них тоже есть акционеры — и это основа их бизнеса, в отличие от Гугла. Если вы сами не занимаетесь исследованиями активности пользователей — то нужно опираться на источники, а не на то, что «мои друзья не пользуются гугл плюсом».
Что касается вашей правоты. Рост активности фейсбука почти стагнирующий. Рост активности гугл плюс огромный — и стабильный (они не сразу получили свои полмиллиарда) — и о падении скорости роста пока говорить не приходиться. Их размер уже сопоставим и гугл плюс впереди всех конкурентов фейсбука.
Ну как можно говорить, о том, что гугл плюс сдулся? Не сдулся он — а раздувается бешеными темпами.
А уж через какой интерфейс это происходит (ютуб и т.п.) — вопрос не такой уж важный. Фейсбук наращивает активность используя интеграцию кнопки лайк на все сайты. Многие просто лайкают и на фейсбук ленту даже не смотрят. Гугл плюс — делает ставку помимо этого на ютуб. Суть соцсети вовсе не в том, чтобы «сидеть на сайте фейсбука или гугл плюса», а в том, чтобы использовать их сервисы, чтобы делиться информацией.
Мысли конечно интересные, но заявления вроде «И тем не менее Google+ — это провал. » не мешало бы подкрепить ссылками и исследованиями, а не только какими то там размышлялками.
Чтобы судить об успехе гугл+ нужно 1) обозначить какие он перед собой ставил цели; 2) выяснить насколько они были достигнуты.
Я уж вообще молчу о совершенно элементарных цифрах.
На октябрь 2013 года Active Monthly “In-Stream” Users у Google+: 540 миллионов. Это практически с нуля в 2011 году.
На декабрь 2013 года аналогичный показатель Facebook: 1230 миллионов. Рост 1-3% в месяц.
Хотелось бы видеть все таки статьи посерьезнее.
Вспомните запрет на публичные аплодисменты после митингов в Белоруси.