Салют, хабровчане!


Вот и очередной понедельник, а значит, по всей стране, да и по всему миру, миллионы людей «опять пойдут на эту работу», в которой их радует только пятница и день получки. Вот и захотелось поделиться своими мыслями на тему мотивации на работе – мотивации себя и других. Я постараюсь показать, что зачастую негативные эмоции, испытываемые от работы, связаны не с родом деятельности, а с неправильной организацией, и что, совершая те же самые действия по-другому, можно добиться поразительных результатов в собственном эмоциональном настрое, что не может не сказаться на результатах. Но обо всем по порядку.

Определить направление бизнеса – это-то понятно. А дальше что? Что делать дальше? Сразу сесть и писать код? «Это глупо» – сказал я себе. Почему глупо – не сказал. Прежде чем писать код, надо сделать много «умных» и «правильных» вещей. Написать код еще успеем. Став предпринимателем, побори в себе программиста. Думай как бизнесмен, а не как кодер. Бизнес – это тебе не хухры мухры. Не думай о технологии, думай о продукте. Главное – это люди, а не технологии. Ну и так далее. Много подумал красивых девизов и афоризмов, которыми мне прожужжали уши в эпоху моей работы по найму. И все эти красивые слова я принимал за свое «понимание бизнеса». Оказалось, применять на практике их не особо-то и получается. И тогда я решил для начала хотя бы назвать свою компанию. Где-то в подсознании с именованием ассоциировался термин «бренд», исследованием которого я и занялся.

С понедельничком (говорят — самым депрессивным в году), хабровчане!
После публикации этой статьи, многие заметили, что я шустрый карьерист, и у меня начали просить совета на тему: как обеспечить карьерный рост в IT-индустрии. Во избежание повторения одних и тех же советов разным людям в личных сообщениях я и пишу эту статью, делясь в ней историей своего собственного карьерного роста и основными наблюдениями, которые я сделал за 13 лет опыта работы в больших и не очень компаниях.
Сразу предупрежу, что не претендую на изложение универсальной теории карьерного роста сферического коня в вакууме, и большинство замечаний искривлено призмой моего восприятия. То, что неоднократно работало в моем случае, необязательно сработает в вашем.

Итак, решение заняться своим делом принято и одобрено хабрасообществом, за что ему огромное спасибо! Очевидно, в первую очередь следует понять, чем я буду заниматься. Решение серьезное – судьбоносное. Вспомним тот же эпичный анекдот:

Встречаются два друга:
— Как дела?
— Да вот, основал новый стартап, очень быстро растём, развиваемся.
— Круто! А в чём суть стартапа?
— Я провёл исследование рынка и решил публичный дом открыть.
— Ого, интересно, и какие цены?
— Анал — $100, орал — $50.
— А классический секс?
— Понимаешь, это ж стартап. В общем, я пока один работаю…

Я тоже один работаю и у меня тоже стартап, так что надо быть предельно осторожным и бдительным при принятии решения.
В данном посте я проиллюстрирую процесс принятия решения. Чтобы процесс был наиболее нагляден, я для каждой идеи ментально рожу своего персонального виртуального апологета, и решение приму учитывая весь этот разброд идей. Заодно покажу, как можно утихомирить такое полчище, коими наполнены переговорные комнаты во множестве больших организаций, и настроить его на конструктивный лад. Итак:

Салют, Хабр!
Недавно я уволился с довольно завидной должности (главного архитектора) в довольно неплохой компании (Acronis) и с непоколебимым решением в мозгу больше не работать по найму переехал из Москвы обратно в Ереван, откуда семь лет назад понаехал в Златоглаво-Нерезиновую. Учитывая необычность произошедшего и часто задаваемый вопрос «но почему?!», я решил разобраться в собственных мыслях и озвучить их вслух для себя самого и тех, кто может почерпнуть в моих размышлениях что-то для себя полезное. Короче говоря, это рассказ о том, почему я оставил высокооплачиваемую перспективную работу в международной компании ради сомнительной перспективы начать собственное дело, и как я собираюсь дальше жить.

Не знаю как остальных, но лично меня настораживают модные слова и технологии типа виртуализации, облаков и BigData. Настораживают, потому что, не вникая в их суть и применимость, люди слепо начинают их использовать, где нужно и не нужно, потому что «другие же это делают!», в итоге создавая решения, в которых проблем больше чем решений (например, считая, что гигабайт — это big data, разворачивают Hadoop, вместо того, чтобы добавить памяти и использовать Excel). Поэтому я особо скрупулезно вгрызаюсь в модные технологии, пытаясь понять их специфику и область их применимости, дабы не поддаться самому «синдрому молотка». В этой статье хочу поделиться некоторыми своими мыслями насчет облачных хранилищ, тем более что таковое завелось у нас в Acronis несколько лет назад.

В компьютерном мире начинать принято с мантры «Hello, world!», но мы на свой страх и риск решили нарушить этот акт инициации ввиду уважительных причин. На этот самый world и так пишется много всякого маркетингового материала, а тут мы решили рассказать исключительно русскоязычной аудитории о накипевшем наборе технологий, из которых мы собираем наши продукты и сервисы.

Введение

После смены рабочей станции начал ставить на нее Micorosft SQL Server 2008 R2 и чуть было не натолкнулся на традиционные грабли, связанные с улучшенной безопасностью в этой версии. Если в Microsoft SQL Server 2005 группа локальных администраторов по умолчанию включалась в роль sysadmin на SQL сервере, то в 2008-й в эту роль не включается никто:

В итоге, в инсталляции по умолчанию получается ситуация, в которой к инстансу не имеет административного доступа никто, то есть сделать с этим инстансом нельзя ничего кроме как периодически перезагружать его. Также такая ситуация возникает, когда тот, кто устанавливал SQL сервер, назначив себя единственным администратором, увольняется — например такая ситуация возникла нашими админами.
Данный пост показывает решение этой проблемы и предоставляет автоматизированное решение этой проблемы в виде скрипта, ровно как и рассказывает историю его написания, иллюстрируя мощь WMI, которая недопустимо замалчивается в литературе и в интернете.

Введение

Часто приходится сталкиваться с клише, что программисты — технари. Почему я это называю клише, а не аксиомой, и является сутью данной статьи. Статья возникла на основании накопившихся мыслей, возникших на собеседованиях разработчиков и прочих смежных профессий, по поводу того, что из себя представляют люди, именуемые программистами.

Миф о технаре

Итак, я бросаю вызов утверждению, что программист — технарь. Не в частном смысле, а в общем. То есть, я не пытаюсь доказать, что нельзя найти программиста, который является технарем. Я утверждаю, что свойство «технарь» для программиста ни необходимо, ни достаточно.

Вступление

Данная статья написана в результате моих неоднократных встреч на просмотре кода с антипаттернами написания не очень читабельных тестов, не последнюю роль в которых играет неправильная работа с тестовыми данными. В рамках этой статьи я раскрою теорию читабельного теста и покажу, как достичь идентифицированных характеристик посредством вдумчивого именования и грамотного применения вынесения вспомогательных методов.

Юнит. Что это такое?

Unit testing принято переводить на русский язык как модульное тестирование. Однако слово «модуль» имеет несколько другой смысловой оттенок, ассоциирующийся со схемой развертывания. Поэтому во избежание ненужных ассоциаций будем использовать англицизм «юнит». Еще раз вспомним, что такое юнит в рамках терминологии юнит тестирования:

Юнит – это фрагмент кода, дающий в данном окружении при определенных входных данных определенные выходные данные.

Заметим, что кроме самого юнита остальные все компоненты этого определения могут быть вырождены в пустое множество, однако чем больше пустых участников в этой заварухе, тем меньше смысла (семантики) содержится в юните.