Краткая инструкция о том, как написать правильную и умную статью.

Нынче в интернете редко встретишь хороший материал. В основном какие-то низкокачественные статейки. Пора открыть завесу тайны и дать реальные советы для написания правильного материала, который выставит вас в самом лучшем свете.

Итак, вы загорелись написанием лучшего в мире материала. Но проблемы вас ждут еще в самом начале - при выборе темы.

Тут есть два проверенных подхода:

1. Выберите какую-нибудь очень противоречивую тему, споры по которой никогда не прекращаются. Примером можут быть "Почему айфон - это только маркетинг и ничего больше". Уверен, что ваши доводы насчет пузыря компании, обошедшей по доходу все нефтяные концерны смогу вызвать немало интереса.
2. Подумайте над темой, которая дает читателю повод поразмыслить над чем-то новым. Тут главное, чтобы это новое при первом прочтении казалось чем-то поистене захватывающим и доселе невиданным. Примером может стать что-нибудь о политике, религии, экономике. Тут есть золотое правило: не надо углубляться в детали. А если вы еще и не в курсе этих деталей, то вообще хорошо. Никто вас все равно проверять не будет, зато имидж человека, способного написать умную и познавательную статью вам обеспечен.

Итак, тема выбрана. Это уже много, но еще далеко не все. Надо же что-то писать. Так как в вопросе вы скорее всего не разбираетесь, то рекомендую поступить так: обычному человеку, чтобы понять, что вы умны, не нужно читать статью. Главное - это уловить полет мысли. В современном мире ни у кого нет много времени, чтобы вникать. Поэтому для начала придумайте броский и сложный для понимания заголовок. Отлично подойдут такие варианты:

• Синергия в современных религиозных течениях
• Субъективизм мышления приверженцев капитализма
• Неокейнсианская парадигма как способ улучшения качества жизни

Такие заголовки изначально ставят серьезный вопрос, а в этом и есть ваша цель. Незачем писать название. которое будет понятно обычному человеку - ведь вы наверняка слишком хороши для того, чтобы пытаться объяснить точку зрения кому-то, не читающему толковые словари за завтраком.

Насчет текста можно дать много рекомендаций, но самая главная - места, где вы чувствуете наибольшие пробелы в знаниях, заполните такими оборотами, которые заставят читателя сосредоточиться на других участках текста, или, если вы вобще ничего не знаете, на картинках. Желательно, но необязательно, попытаться хотя бы в начале статьи приводить какие-нибудь (пусть даже и притянутые за уши и ничем не подкрепленные) аргументы. Это позволит большему количеству людей убедиться в вашей адекватности до тех пор, пока они не перейдут к более сложному материалу статьи. Тогда они просто решат, что вы умнее их и лучше знаете, о чем говорите. 

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

Прометей как он есть

Фильм шел в кинотеатрах уже достаточно давно, а значит целесообразность рецензии находится под вопросом, но я все же рискну и выскажу свою точку зрения на новое творение Ридли Скотта.

Есть такие фильмы, которых ждешь с нетерпением, и по мере приближения премьеры только завышаешь свои ожидания от будущего просмотра. В итоге может случиться так, что даже очень неплохое кино из-за этих самых ожиданий вызывает чувство разочарования после сеанса. Чего-то похожего я и боялся, когда шел в кинотеатр.

Дело в том, что Ридли Скотт, так любимый многими после своего «Гладиатора», снимал весьма посредственное кино в последнее время. А тут с первого тизера и до последнего трейлера ожидалось нечто потрясающее. Забегая вперед, скажу, что несмотря на обширную рекламу и завышенные ожидания, фильм получился отличным. Есть, конечно, нюансы, но о них — ниже.

Когда смотришь научно-фантастические фильмы в жанре триллера, обычно сложно ожидать умопомрачительного сюжета. Стандартная история — какая-нибудь пакость в космосе нападает на корабль, а герои стоически ей противостоят, попутно пытаясь выжить и не забывая отпускать остроты вперемешку с пафосом. Хотел бы я сказать, что «Прометей» как-то особенно выделяется своей сюжетной составляющей на фоне кучи однотипных по своей задумке произведений. Но это было бы лишь отчасти правдой. История, которую нам рассказывает Ридли Скотт, все так же банальна по задумке. Вместо изобретения нового слова в жанре научной фантастики, режиссер вместе со сценаристами решили внести таинственность в повествование. И они настолько увлеклись процессом, что после выхода из кинотеатра навязчивая мысль «Что это было?» никак не хочет покидать голову. Вопросов после просмотра картины становится куда как больше, чем до его начала. Ну, а намек на продолжение заставляет кусать локти и недоумевать, как можно ждать еще несколько лет, пока (и если) выйдет вторая часть.

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

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

Хотелось бы отметить игру актеров. Но, честно говоря, ничего особенного из этого бы не получилось. Единственным запоминающимся актером является Фасбендер в роли робота, помыслы и мотивы которого понять решительно невозможно. Справился Майкл очень неплохо, успев попутно поговорить на каком-то очень древном языке и даже дожить до конца фильма. Остальные актеры выглядели не очень внятно, и вспомнить что-либо о них по прошествии месяца после просмотра мне уже очень сложно.

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

Дружба

Забыл опубликовать, поэтому появляется только сейчас.

Нельзя пожать друг другу руки со сжатыми кулаками.

Индира Ганди

Как приятно с утра, когда на улице стоит отличная погода предаться мечтаниям! Вот и Леша, заварив себе чашку превосходного зеленого чая, уселся поудобнее в большое кожаное кресло, которое ему подарили друзья на 25 летие, и стал думать о том, как он потратит заработанные деньги. Если знать Лешу недостаточно долго, то можно сложить о нем впечатление поверхностного и в большой степени эгоистичного человека, для которого материальная выгода стоит выше духовного богатства. Но это лишь отчасти правда. Леша любил тратить деньги. При этом он редко когда задумывался о других и спускал свои сбережения со скоростью пули в основном лишь для собственного увеселения. Однако делал он это исключительно из-за своей простоты деревенского парня, в один прекрасный день перебравшегося в столицу. Он никогда не думал о других не потому, что ему было все равно. Такие мысли вообще не могли посетить его головы так же, как сложно себе представить литератора решающего дифференциальные уравнения.
Помимо прочего, Леша очень любил играть в карты. Нередко он полностью проигрывался, надеясь, что на следующей раздаче ему уж точно повезет. Вот и сейчас, Леша сидел , мечтая о том, как он отыграется, купит себе дом, машину и больше никогда не будет ни в чем нуждаться. К сожалению, как это часто бывает, Леша никогда не умел вовремя остановиться и даже выигранные изредка деньги, не могли у него задержаться надолго. Но мечты! Мечты уносили Лешу далеко в те места, где у него была своя прислуга, одетая в кружевные наряды, как это было принято в эпоху Ренессанса, конюшня с прекрасными жеребцами и несколькими большими хаундами, охранявшими его дом от посягательства чужаков.
Внезапно раздался телефонный звонок, который выдернул Лешу из его мечтаний и вернул к суровой действительности. Немного расстроившись, Леша поднял телефонную трубку и услышал уже привычные вопли начальника о новой партии товара, которую срочно нужно доставить на склад. Осознавая, что у него сегодня выходной, Леша тем не менее не решился спорить и согласился через час подъехать к заводу, чтобы забрать товар. А как было не согласиться, когда сверхурочные оплачиваются по двойному тарифу, а Леша был должен своему другу Саше еще с прошлого месяца после крупного проигрыша.
Выйдя из дома, Леша сел в грузовик и вырулил на шоссе по направлению к заводу, где его фирма закупала весь товар для дальнейшей продажи. В компании дела шли не важно, и ситуация не собиралась улучшаться. Но так как зарплату не задерживали и не заставляли, за редким исключением, работать больше положенного, Леша и не думал жаловаться. Многие из его друзей находились в гораздо худших условиях, боясь остаться без заработка.
За стеклом сияло солнце и мысли Леши постепенно вернулись к его мечтам о сказочном богатстве, которое он в один прекрасный день обязательно выиграет в карты.
На автомате управляя автомобилем, Леша не заметил, как на пешеходном переходе на дорого вышел молодой парень. К реальности его вернул глухой удар головы парня о лобовое стекло грузовика. Капли крови, брызнув из раны стали образовывать причудливые узоры на стекле, расходясь, словно лучи солнца, в разные стороны. Застывшая улыбка на лице парня так и не успела смениться на другую эмоцию, которая лучше бы подходила под ситуацию. Глаза его уже ничего не видели, лишь только внутренности, распоротые какой-то из деталей автомобиля вываливались из его живота, будто какие-то живые организмы, представляя собой ужасающее зрелище. Леша резко ударил по тормозам, но так и не смог остановится до того, как грузовик переехал отброшенное ударом тело мальчика, перемалывая в кровавое месиво то, что осталось от его лица.
Сказать, что Леша был расстроен - не сказать ничего. Он вряд ли скоро сможет поиграть в карты. И лишь одна мысль немного успокаивала его - уже не придется отдавать карточный долг Саше. Это событие стало началом конца их крепкой дружбы.

О зарплате программистов

Сегодня беседа с одной своей знакомой программисткой навела меня на рассуждения о том, как же все-таки надо оценивать затраты труда программиста. Вот я и решил поделиться своими соображениями. Сразу оговорюсь, что я не являюсь экспертом в этой области (имею ввиду оценки производительности), и все нижесказанное является плодом моего воображения, критику к которому я с удовольствием приму в комментариях.
Для меня производительность - это характеристика, показывающая, насколько эффективно один человек работает. Сама по себе эта характеристика бесполезна ввиду того, что никак не позволяет влиять на "цену" этого сотрудника. Если существует всего один программист, то его цена никак не связана с его производительностью. Поэтому интереснее рассматривать производительность как способ влиять на цену труда программиста в контексте рынка, когда конкуренция устанавливает цены. Здесь гораздо важнее становится относительная производительность, показывающая насколько один программист лучше другого. Так как же можно измерить эту величину?
Я считаю, что за некоторыми исключениями, никак. Рассмотрим различные способы, которые я нашел в интернете:

• Количество строк кода. Наверное самый идиотский способ, которые едва ли применяется где-либо на практике. Эта характеристика не показывает вообще ничего, что не является секретом для любого, кто сталкивался с программированием.
• Количество реализованных сценариев (use cases). В теории это могло бы считаться адекватным способом измерить производительность, поскольку опытный программист может оценить сложность одной задачи относительно другой. Но появляется сразу несколько нюансов: задачи могут зависеть друг от друга, некоторые задачи могут иметь низкую сложность, но занимать много времени (пример - однотипный рефакторинг под уже запрограммированную архитектуру в противовес разработке архитектуры даже небольшого участка системы). В итоге становится непонятным, как сопоставлять сложность и длительность работы над задачами. Как оценить, что один человек работает производительнее другого?
• Гипотетический случай, когда программисты делают одну и ту же задачу, а затем сравниваются результаты. Даже в этом случае нельзя судить о производительности, если только вы не намереваетесь платить за конкретно эту задачу. Выбор подхода, например, чаще всего является субъективной категорией для более менее больших систем.

Наверняка есть и другие способы цифрами оценить, насколько один программист лучше другого. Я считаю, что ни один из них нельзя использовать как достоверный. Это связано с тем, что написание кода представляет собой творческий процесс, который уникален (очень часто, хотя и не всегда) для различных задач. В связи с этим программисты будут вести себя по разному в зависимости от поставленных целей. Здесь я даже не пытаюсь учесть влияние внешних факторов, которые тоже могут менять ситуацию.
Но как тогда можно решить. кому сколько платить? Я бы выделил 2 варианта для относительной оценки производительности программиста:

1. В силу опыта и знаний, один программист может выполнить работу, которую второй выполнить в принципе не в состоянии, либо не сможет сделать этого за какое-то разумное время. Например, я не представляю себе, чтобы я смог спроектировать операционную систему даже в общих чертах. У меня банально не хватит опыта решения архитектурных задач, чтобы это сделать. Я бы назвал этот пункт единственно возможным способом объективно разделить программистов. Это я и имел ввиду под исключением. Но здесь идет деление на "уровни", на каждом из которых по-прежнему много людей.
2. В каждой команде есть менеджер. И этот человек является ключевой фигурой в оценке производительности. Очевидно. что его суждения всегда носят субъективный характер. Но он  руководствуется двумя вещами: ситуацией а рынке и в команде. Программисты так или иначе представляют уровень зарплат коллег, а значит могут оценивать затраты и отдачу в работе. Если в команде нет по этому поводу конфликтов, значит менеджер держится хорошо в плане оценки производительности. А корректировать стартовую точку ему вполне может помогать ситуация на рынке. Иначе команда может распасться ( это тоже упрощение, конечно) из-за неадекватной оценки  в целом. В принципе рынок можно было бы не рассматривать, а обобщить пример в том смысле, что все представляют зарплаты всех, а задач менеджера дать тебе оценку относительно рынка, с которой ты был бы согласен.

Зачем я все это пишу? Мне хочется показать рассуждениями, что нельзя применять количественные оценки работы программиста. Дело в том, что затраты усилий внутри команды хорошо видны. И видны они менеджеру и команде. Я в данный момент не знаю, как эти затраты можно померить объективно. Если команда ощущает, что их усилия вознаграждаются соответственно, то проблем быть не должно. Но если кто-то пытается тыкать какими-то числами, которые скорее всего не соответствуют реальной картине, то конфликтов не избежать.

Как я ходил на первый митап по MongoDB

О MongoDB я услышал уже достаточно давно. Услышать-то я услышал, но что это такое никогда особо не интересовался. Мои знания всегда ограничивались тем, что это такая NoSQL база, с которой можно общаться на JS.
И тут вдруг появляется юзер группа, а сразу за ней митап по этой самой базе данных. Такого, я, естественно, не мог пропустить, причем сразу по двум причинам. Во-первых, давно хотелось познакомиться с чем-нибудь подобным, а во вторых мне всегда хотелось посетить встречу, где я буду настолько не в теме, что даже вступительный доклад позволит узнать мне много нового. Второе продиктовано тем, что на стандартных конференциях по .NET рассказывают в основном стандартные вещи, которые чаще всего мне и так известны.
Накануне встречи я решил, что нужно ознакомиться хотя бы с основами, чтобы понимать, о чем вообще мне будут рассказывать. И вот, вооружившись компьютером и желанием узнать что-то новое, я пошел на mongodb.org и несколько часов пытался экспериментировать с первой в моей жизни NoSQL базой данных. Стоит признать, что я действительно очень впечатлился и получил нужный заряд мотивации для дальнейшего изучения.
Придя на митап, я сразу же узнал две новых вещи: у эпама реально крутой офис на Независимости 186, а еще то, что-кто-то все таки пользуется Google Hangout (мы связывались с челами из Штатов, которые высказали свои поздравления в связи с созданием юзер группы).
Первый доклад, что вполне логично, был введением в то, что же из себя MongoDB представляет. Сначала было много положительного относительно возможностей, которые, к слову, впечатляют. Когда начались вопросы, оказалось, что все не так уж и гладко. Две самых главных вещи, которые меня расстроили - это проблемы с надежностью и тот факт, что MapReduce отрабатывает в одном потоке. С другой стороны, это в очередной раз навело меня на мысль, что не стоит применять традиционные подходы к решению задач, к инструменту, который работает по-другому. Похожее ощущение у меня было, когда я знакомился с Erlang. Вроде возможности схожи с объектно-ориентированными языками, но надо понимать, что эффективно позволяет работать именно правильный подход.
Следующим докладом нам рассказали о проблемах на реальных проектах и о том, как такие проблемы можно решать. На самом деле для меня оказалось важным, что по сути мое первое знакомство с MongoDB не было просто рекламой этой базы данных. Естественно, я не в курсе всех нюансов, но подход, когда видны не только положительные, но и отрицательные стороны позволяет изначально настроится на то, что для использования придется не просто изучить API, а проникнуться идеологией что ли. Что-что, а проникаться новой идеологией я очень люблю :)
По факту получился отличный митап, где даже не монго было самым главным. Гораздо важнее то, что предоставилась отличная возможность познакомиться с людьми, которые полны энтузиазма и рвения изучать что-то новое и делиться своими знаниями.  Очень рад, что сходил, даже если в итоге мои пути с MongoDB разойдутся.

P.S. Ах да, чуть не забыл. Когда после митапа мы сидели за пивом и пиццей, то немного попугали одного студента по поводу того, насколько же уныла и ужасна работа программиста в Беларуси. Дима, на самом деле главное - это проект, куда ты попадешь, так что не надо думать, что все так уж плохо. С хорошим менеджером и интересной задачей абсолютно не важно в какой компании ты работаешь, как не важно это и в случае плохого менеджмента/проекта.

Вечность

Это мой первый рассказ, так что не судите строго. Имена все вымышлены.

Величие человека заключается в том, что он –

единственное из всех творений,

способное превратить мгновение в вечность

Иоганн Вольфганг Гёте

История эта началась несколько лет назад в одном маленьком городке, который ничем особенно не выделялся среди множества таких же как он. Очень даже может быть, что в них тоже происходило нечто подобное.
На улице стояла чудесная погода, и Леша не без удовольствия решил прогуляться до работы вместо того, чтобы задыхаться от нехватки воздуха в общественном транспорте. Солнце еще только недавно вышло из-за горизонта, но день обещал быть жарким, и прохожие все как один были в легкой одежде, а девушки надели короткие платьица. От этого хорошее настроение у Леши только улучшилось.
Он подошел к светофору, посмотрел по сторонам и начал переходить дорогу. Но тут из-за поворота выскочил грузовик, сбил Лешу, раздробив добрую половину его костей. Последнее, что увидел перед собой парень перед тем, как навсегда окунуться в небытие - это свои врутренности, которые вываливались из распоротого живота.
В тот день умер не только Леша. Саша, читавшая книгу и находившаяся на другом конце земного шара, внезапно почувствовала, как что-то внутри нее разбилось, перестало существовать. Она осознала, что эту пустоту больше ничто уже не сможет восполнить.
Вот и подошел к концу их короткий, но такой страстный роман.