понедельник, 1 июля 2013 г.

Анонс: English Transcripts

Друзья и камрады,
Я рад представить новый проект Константина Зайцева:

English Transcripts  – Обучающий блог с англоязычными аудио- и видеозаписями, их расшифровкой, параллельным переводом и разбором

Хотелось бы отметить, что ведением проекта занимается профессионал в сфере обучения английскому языку. Кроме параллельного англо-русского перевода вы найдете аудио начитку текста.

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

Успехов Константину в этом деле, а читателям –  нового, интересного материала!

пятница, 29 июня 2012 г.

Parallel lines: блог параллельных переводов от Алексея Потапова

Уважаемые читатели!

Я рад представить вам новый блог с параллельными переводами научно-популярных статей, комиксов, картинок и многих других интересностей.

Это блог «Parallel lines || http://ruentxt.blogspot.com» от Алексея Потапова.

Свой блог Алексей завел очень недавно, но уже сейчас в нем есть серьезный перевод статьи «What is time?» и около 10-ти переводов увлекательных комиксов.

Друзья, если вам интересны параллельные переводы – подписывайтесь и читайте блог Алексея.

И если у вас есть свой блог параллельных переводов – напишите мне письмо или оставьте комментарий к любому посту – я обязательно анонсирую его здесь.

Алексею я желаю успехов в новом интересном и полезном деле.

вторник, 19 июня 2012 г.

Параллельные тексты: как это работает?

Друзья, в комментариях и по почте мне приходят благодарности и предложения помочь в создании переводов.

И сейчас, я очень жестко и грубо отвечу: мне не нужны помощники.

Мне нужны – конкуренты. Это, действительно, очень просто. И я готов поддержать вас!
Для того чтобы начать собственный проект – нет необходимости в глубоких технических познаниях.
Microsoft Word, Блог на Blogger, Google Translate и Поиск Google – это все инструменты, которые я использую в подготовке параллельных текстов. Начать может каждый.

Многие скромно подчеркивают свой средний или низкий уровень владения английским. Тут ничего нет страшного – переводить то вы всё равно будете на русский. Ну ладно, открою вам секрет, мой английский до уровня Advanced тоже недотягивает. Но, с каждым переводом, мои навыки совершенствуются, и заряда хватает очень надолго

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

Я не отрицаю пользу от подобных курсов английского, просто конкретно мне там было не интересно. Я предпочитаю слушать доклады IT-шной тематики на английском, читать англоязычные статьи с Hacker News, слушать IT-шные подкасты, смотреть в оригинале фильмы, сериалы (Family Guy, South Park, The Walking Dead, The River… ), и время от времени переводить и делится интересной информацией из англоязычного интернета для русскоязычной аудитории. Это мне делать интересно, а читать про то, как фермеры собирают кабачки – нет.

Вы
Тут я хочу объяснить, почему мне не нужны помощники, а нужны конкуренты. Все очень просто, как и то, что на вкус и цвет – все фломастеры разные.

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

Конкуренция порождает разнообразие и заставляет развиваться. Вы – независимы.
Но, это не значит, что если мы конкуренты – значит враги. Нет! Нет! Нет!
Мы можем помогать друг другу. Со своей стороны, я готов всячески поддерживать и пиарить ваши блоги: делать анонсы, добавить вашу RSS ленту. Если будет нужно, то можно будет создать группы на Фейсбуке/Вконтакте, есть еще идеи? – Предлагайте.

Они
Я бы еще раз хотел подчеркнуть, что с точки зрения изучения английского языка, наибольшую выгоду получает именно переводчик. Но, как показывает практика, сам продукт – параллельный текст – интересен и полезен читателям. Очень приятно осознавать, что делая что-то исключительно в своих интересах – ты помогаешь и другим людям. И читатели благодарят тебя в комментариях и по email.

Кроме того, для меня особенно полезны комментарии, в которых читатели поправляют мой русский и английский. Конструктивная критика – это очень полезно.
Ну, и конечно же, приятно видеть когда твой русскоязычный перевод на Хабре люди обсуждают и спорят на тему поста. Это значит, что когда я берусь за перевод статьи, интересной мне – то оказывается, что тема интересна еще многим людям.

Техническая сторона и процесс
Поиск статьи:
Я просматриваю Hacker News и Reddit просто потому что мне нравится читать новости в мире IT. Я вижу статью с провокационным заголовком, вчитываюсь, и понимаю, что это то, что мне нужно для перевода и то что мне интересно будет перевести на русский язык.

Инструменты:
Из браузера я копирую текст в Microsoft Word и сразу же сохраняю его на рабочий стол, чтобы файл чаще напоминал о себе.

Единица перевода текста для меня – это один параграф. Скопировав текст в Word, я перевожу первый параграф. Сам текст в редакторе выглядит почти также как и в блоге: сверху параграф английского текста, а снизу – русский. Только русский вариант я отмечаю не светло-серым цветом, а более ярким, светло-фиолетовым.

Перевод может занять некоторое время. Свободного времени у меня на это хобби тоже не много, так что статью я могу переводить от нескольких часов – до нескольких дней.
После чего я публикую параллельный текст сначала в свой блог (раскрасить английский и русский текст можно в визуальном редакторе, но я использую для русского текста специальный стиль <span class=”rustext”> ).
Русский перевод я публикую на Хабрахабр, чем обеспечиваю приток новых читателей.

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

P.S.: Обратите внимание на следующий ресурс коллективных переводов:
http://notabenoid.com/

понедельник, 18 июня 2012 г.

No Matter The Decision You Make, It’s Always Wrong

Без разницы, какое решение вы примете – оно всегда будет неверным

I was scared to quit my first real job. I didn’t want to tell my boss that I was leaving. I know she was going to be mad at me. I was leaving for a competitor who was also going to pay me more. I was a traitor. How dare I leave a company for better money. She kept telling me that I was making the wrong decision by leaving and that I shouldn’t be making a decision based on how much the new employer is going to pay me. She was right, I shouldn’t base my decision on that. That obviously wasn’t the reason I was leaving, but she was convinced that was the only reason I wanted to leave.
Мне было страшно уходить со своей первой работы. Я не хотел говорить своей начальнице что ухожу. Я знал, что она будет в бешенстве. Ведь я уходил к конкурентам, которые собирались платить мне большую зарплату. Я был предателем. Да как же я мог покинуть компанию ради больших денег. Она продолжала говорить мне, что покидая компанию – я принял неправильное решение; и что нельзя принимать решение, опираясь на сумму, которую новый работодатель готов заплатить. И она была права, я действительно не должен был принимать такое решение, отталкиваясь лишь от суммы. И это, конечно же, не было основной причиной моего ухода, но она пыталась меня убедить, что это – единственная причина.



Did I make a wrong decision by leaving? Since this was a while ago, I can safely say I made the right decision. However, If I ask my old boss If I made the right decision she would still tell me that it was the wrong decision. It doesn’t even matter if I quit and created Facebook and became a billionaire. In her eyes, I made the wrong decision. It took me a while to realize that every decision I make will always be wrong. Someone is always going to be mad at me regardless of the decision. There will be someone who is negatively affected by your decision, even the small one’s.
Вы думаете, я принял неправильное решение об уходе? Так как это случилось довольно давно, я могу с уверенностью сказать, что принял правильное решение. тем не менее, если бы я сейчас спросил свою прошлую начальницу, верным ли было мое решение, то получил бы однозначный ответ – нет. И без разницы: пусть я ушел и создал новый Facebook или стал миллиардером. В ее глазах – я принял неправильное решение. Спустя некоторое время, я осознал, что любое решение, которое я бы не принял – было всегда неверным. Независимо от твоего решения, всегда будет человек, который на тебя будет злиться. И всегда будут люди, на которых негативно повлияют твои решения, даже самые незначительные.



When I quit my job recently to start my own company, everyone thought it was a bad decision. There was actually not one person who thought my decision was right. I had a great, steady job with very marketable technical skills, and here I am quitting my job and going completely on my own.
Когда я уходил со своей прошлой работы чтобы основать собственную компанию – все думали что это плохое решение. Вообще-то не было ни одного человека, который бы меня поддержал. У меня была замечательная работа с очень востребованными на рыке труда навыками, и тут – я решил уволиться и заняться своим делом.

6 Months in, I can safely say that I made a great decision. I have reached many of my goals, and I have managed to completely replace my old business network which was essentially worthless to me. If you ask me, I made a great decision. Best decision I have made in a while. If you ask my previous employer, they still think it was a wrong one. If you ask my family, they’ll tell you that they aren’t convinced that my decision was right.
Через 6 месяцев, я уверенно могу сказать, что это было замечательное решение. Я достиг многих своих целей и мне удалось полностью заменить все свои прошлые бизнес-связи, которые попросту стали бесполезными. Если вы спросите меня – то я скажу, что принял замечательное решение. Самое лучшее решение за последние несколько лет. А мой прошлый работодатель по-прежнему думает, что я был неправ. Если вы спросите мою семью – они по прежнему сомневаются, что я принял правильное решение.

They are still pushing to get me back to the corporate world. Now, If I ever decide to leave the startup world and go back into the corporate world*, that will make a lot of people happy, except my new startup friends. To them, I will always be a traitor.
Они по-прежнему хотят добиться того, чтобы я вернулся в корпоративный мир. И сейчас, если вдруг я решусь покинуть мир стартапов и вернусь в корпоративный мир – это сделает счастливыми многих людей, кроме моих новых друзей по стартапу. Для них, я навсегда останусь предателем.



Автор оригинального текста: Robbie Abed
Перевод: Дмитрий Жарий
Оригинал: No Matter The Decision You Make, It’s Always Wrong.

суббота, 21 мая 2011 г.

Q:Are we not engineers?

Thinking Metaphorically about Software Engineering
Думая метафорически о разработке программного обеспечения


Years ago I heard a comparison of software engineering to chemical engineering. I believe the intent of the analogy between the two fields was due to the fact that software engineering is a very young discipline just as chemical engineering was in recent history.
Несколько лет назад, я слышал, как сравнивали инженерию ПО и химическую технологию. На мой взгляд, причиной такого сравнения было то, что разработка программного обеспечения является очень молодой дисциплиной, как и химическая технология, которая появилась всего лишь несколько веков назад.
Metaphors get used a lot in our industry, in Chapter 2: "Metaphors for a Richer Understanding of Software Development" of Steve McConnell’s Code Complete they are discussed in some detail. In that chapter he cites the following: Метафоры и раньше очень широко использовались в нашей индустрии, во второй главе «Метафоры, позволяющие лучше понять разработку ПО», книги Стива Макконнелла «Совершенный код» детально рассматриваются самые различные метафоры. Вот некоторые цитаты из этой главы:
A confusing abundance of metaphors has grown up around software development. David Gries says writing software is a science (1981). Donald Knuth says it's an art (1998). Watts Humphrey says it's a process (1989). P. J. Plauger and Kent Beck say it's like driving a car, although they draw nearly opposite conclusions (Plauger 1993, Beck 2000). Alistair Cockburn says it's a game (2002). Eric Raymond says it's like a bazaar (2000). Andy Hunt and Dave Thomas say it's like gardening. Paul Heckel says it's like filming Snow White and the Seven Dwarfs (1994). Fred Brooks says that it's like farming, hunting werewolves, or drowning with dinosaurs in a tar pit (1995). Which are the best metaphors?
Множество метафор, описывающих разработку ПО, смутит кого угодно. Дэвид Грайс утверждает, что написание ПО — это наука (Gries, 1981). Дональд Кнут считает это искусством (Knuth, 998). Уотте Хамфри говорит, что это процесс (Humphrey, 1989). Ф. Дж. Плоджер и Кент Бек утверждают, что разработка ПО похожа на управление автомобилем, однако приходят к почти противоположным выводам (Plauger, 1993, Beck, 2000). Алистер Кокберн сравнивает разработку ПО с игрой (Cockburn, 2002), Эрик Реймонд — с базаром (Raymond, 2000), Энди Хант (Andy Hunt) и Дэйв Томас (Dave Thomas) — с работой садовника, Пол Хекель — со съемкой фильма «Белоснежка и семь гномов» (Heckel, 1994). Фред Брукс упоминает фермерство, охоту на оборотней и динозавров, завязших в смоляной яме (Brooks, 1995). Какие метафоры самые лучшие?

Additionally, in a recent blog post by Chris Aitchison, titled "You are NOT a Software Engineer!" the gardening comparison is also made, including the following statement:
В дополнение ко всему, Крис Ейтсон в своем посте под названием «Вы НЕ инженер-программист!», проводит аналогию с садоводством, делая также следующие заявление:
You can’t just plant the same plants as Facebook, Flickr or Twitter and expect them to take root regardless of the quality of your gardeners or the climate of your organisation.
Вы просто не можете сажать те же саженцы, что и Facebook, Flickr и Twitter и ожидать, что они укоренятся, независимо от качества ваших садовников или климата организации.
The point of the metaphor is that each company is like a different ecosystem with a different climate and different soil conditions, but could you not make the same metaphor about engineering, in civil engineering would not building a levee or a dam or a bridge or a highway all have different "ecosystems" as in chemical engineering the following might be different "ecosystems:" manufacture of penicillin via fermentation, manufacturing sulfuric acid, petroleum refining, or extracting aluminum from molten bauxite via electrolysis. So it seems that you can make a number of different metaphors fit anything. I confess that I really don’t care for the farming/gardening metaphor.
Идея этой метафоры в том, что каждая компания – это как отдельная экосистема, со своим климатом и своей почвой, но, насколько применима эта метафора для инженеров-строителей; выходит так, что вы не можете успешно построить дамбу или плотину или мост или шоссе, потому что у каждого этого сооружения своя «экосистема»? Точно так же как и в химический инженерии, для следующих продуктов могут быть свои «экосистемы»: для производства пенициллина при помощи ферментации, производства серной кислоты, переработки нефти или извлечения алюминия из бокситов по средствам электролиза? Похоже, что вы можете придумать множество различных метафор, которые подойдут подо что угодно. Признаюсь честно, я не любитель садоводческих и сельскохозяйственных метафор.
Another metaphor appears in a recent post By Chip Camden "Why programmers should study the art of programming":
Еще одна метафора появилась в недавнем посте Чипа Камдена «Почему программисты должны изучать искусство программирования»
To the average programmer in the trenches, debating the theory of computation is like discussing the chemical properties of saltpeter while in a gunfight: it may all be correct, but it doesn’t apply directly to the problem in front of them.
Обсуждение теории вычислений, для среднестатистического программиста, сидящего в траншее, это все равно, что обсуждать химические свойства селитры в то время, как идет перестрелка: все может быть очень правильно и толково, но не относится непосредственно к проблеме, стоящей перед ним.

Now being in the trenches could refer to trench warfare or pre-mechanization mining or construction, but the gunfight statement implies the former. The gunfight/battle analogy gets used from time to time and I don’t think it is very fitting. Gunfights and warfare are destructive endeavors, which lead to the death of people: "It's a hell of a thing, killin' a man. Take away all he's got, and all he's ever gonna have." When you take a life, not to trivialize it, you are destroying all the information a person knows, in that way it is similar to the deletion of a file or loss of data. The analogy is based on the idea that the people doing the actual work have to deal with "front line" level stresses of getting the job done and the general chaos that seems to befall software projects. But software construction is a creative process not a destructive one.
Фраза «быть в траншее» может означать и «окопную войну» и добычу материалов для строительства, но, заявление о перестрелки явно подразумевает первое. Метафоры о войнах и перестрелках в разработке ПО, появляются время от времени, но я не думаю что они уместны. Перестрелки и войны – это разрушающие действия, сопровождающиеся гибелью людей: «Это не просто — убить человека. Ты отбираешь всё, что у него есть. И его будущее тоже». Отнимая жизнь другого человека, вы уничтожаете всю информацию, которую знал этот человек, и это подобно удалению файла или потере данных. Эта аналогия основана на той идее, что человек, пытаясь выполнить свою работу и бороться с хаосом, который вот-вот поглотит и разрушит весь проект, подвергается стрессам, вполне соизмеримым тем, что и на линии фронта. Но, разработка программного обеспечения – это конструктивный процесс, а не деструктивный.
I don’t mean to didactic or facetious but I think it’s also particularly ironic that he chose to reference saltpeter, which is a constituent in black powder, an older form of gunpowder that has been replaced by smokeless powder. Actually in the late 1800’s understanding the problem with black powder, which is based on the chemical properties of saltpeter, in some cases made the difference between winning and losing in a gunfight or battle. Black powder forms a thick white smoke, in some gun battles if you had smokeless powder you could remain concealed, but if you had black powder you were sending up a big smoke signal that revealed your position. This new technology gave you a distinct tactical advantage that could save your life. This smoke created another problem which was when a lot of people fired a lot of rounds it created an immense amount of smoke so that you could no longer see what you were shooting at in fact the term "fog of war" is thought to be based on this phenomenon.
Я не хочу быть поучающим или особо остроумным, но мне кажется особо ироничным то, что для своей метафоры Чип выбрал именно селитру, которая входит в состав черного пороха, устаревшей формулы пороха, которая была заменена бездымным порохом. В конце 1800-х годов, понимание проблемы черного пороха, которая основана на химических свойствах селитры, в некоторых случаях решало исход боя. Черный порох образует густой белый дым, и в некоторых боях, имея бездымный порох, вы могли оставаться незамеченным, но используя черный порох, вы создавали большой заметный дымовой сигнал, который выдавал вашу позицию. Новая технология предоставляла преимущества, позволяющие сохранить вам жизнь. А дым от черного пороха создавал еще одну проблему, так как ведя огонь продолжительное время, накапливалось огромное количество дыма, через который стрелок уже не мог видеть цель. Этому явлению было дано имя «туман войны».



I am not sure how apt the chemical engineering metaphor is either, but there are some interesting parallels. The early chemical manufacturing process to produce sulfuric acid is called the Lead chamber process and it was invented in the mid 1700s. The process was not very well understood and was inefficient in that it required the use of expensive nitrates often from Chile which were partially lost as nitric oxide vapor, and it took over a hundred years before a way to recycle part of the nitrates was added to increase the efficiency of the process. The discipline of chemical engineering was codified in the late 1800s when college curricula and associations for chemical engineering were created.
Я не знаю, насколько будет уместной эта химическая метафора, но все же прослеживаются интересные параллели. На заре становления химической промышленности для добычи серной кислоты использовались большие промышленные свинцовые камеры, которые были изобретены в середине 18-го века. Этот процес был не очень хорошо изучен и был неэффективным в том, что требовал дорогостоящих нитратов, привозимых из Чили, которые за время перевозки частично окислялись и испарялись. Только через 100 лет ученые нашли способ перерабатывать нитраты для увеличения эффективности производства. Только тогда, в конце 19-го века, химическая технология как дисциплина, была надежно закреплена в программах колледжей и была создана отдельная ассоциация.
Over time the sciences of chemistry and stoichiometry advanced as did thermodynamics which made major steps forward around the same time. I am over simplifying here but eventually little understood processes that were discovered and tweaked by trial and error became better understood and could be controlled and improved empirically by applying the laws of science and mathematics.
С тех пор передовые науки химии и стехиометрии, точно так же, как и термодинамика, сделали важнейшие шаги в перед в своем развитии примерно в одно и то же время. Я все немного упрощаю, но в конечном итоге, в это время, мало понимаемые процессы, которые были обнаружены и отлажены методом проб и ошибок, стали более изученными и контролируемыми и улучшенными эмпирическим путем применения законов естественных наук и математики.
Another parallel is the focus on reusable processes, in that if you are building a new plant to manufacture sulfuric acid you don’t want to design it from scratch each time. An interesting and abstract parallel is that both disciplines have their entropies, i.e. thermodynamic vs. information. A social parallel may be the transformative effect that software is having on our lives and our society is as profound as that of industrial scale chemical production, this keyboard and almost thing I can see right now has been influenced in some way by chemical engineering. Also what are the negative sides of these industries, what problems are we creating by the unregulated and somewhat opaque policies in regards to chemicals and what might some of the issues with software and IT be?
Следующая параллель заключается в процессах многоразового использования, а именно в том, что когда вы строите новый завод по производству серной кислоты, вы не хотите придумывать его с нуля каждый раз. И в любой дисциплине есть факторы хаоса и неоднозначности, в том числе и в термодинамике и в информатике. С точки зрения социологии, сегодня программное обеспечение оказывает на нашу жизнь не меньшее влияние, чем химическая промышленность, ведь именно эта клавиатура, на которую я смотрю, и почти все, что я могу видеть – продукты химической промышленности. Но, какие негативные последствия могут повлечь за собой эти химические вещества, и могут ли быть эти проблемы химической промышленности родственными к проблемам разработки программного обеспечения?
Now admittedly there is pretty big difference between a physical chemical process or the physical construction of a bridge and software construction. There are obvious parallels to building things in that people have to come together to build something that is greater than what one single individual could build. And there are similarities to chemical processes in that once you build it that you have keep it up and running and you will probably need to do maintenance and make improvements while it is operational and even in some cases take it off line or build a new one in parallel while the old one is still in production. Also might we possibly view computer science and math as related to software engineering as chemistry, stoichiometry and thermodynamics are related to chemical engineering?
Сейчас, правда, есть довольно большая разница между химической индустрией, строительством мостов и разработкой программного обеспечения. Общим со строительством есть то, что людям необходимо собраться вместе, чтобы создать нечто большее, что невозможно сделать одному человеку. Сходство разработки ПО и химической промышленности в том, что если вы уже создали и запустили некоторый продукт, вам необходимо его обслуживать и вносить необходимые улучшение в том время, пока продукт работает, а в некоторых случаях снять его с линии или создавать новый продукт параллельно, пока старая версия все еще в продакшене. Точно так же мы могли бы рассмотреть информатику и математику как тесно связанные науки с разработкой программного обеспечения, точно как в химии, стехиометрия и термодинамика связана с химической промышленностью.



Like Donald Knuth I too think there is an artistic element to software, this idea is not incongruent with building or bridge architecture which is a process that organizes groups of people to build something that can be beautiful. Perhaps a possible analogy for software engineering would be the construction of a bridge where we still don’t really understand all of the physics behind it or the best way to go about it. As a result when we are done it might stay up and it might not and it will probably take longer than we thought to build it.
Соглашаясь с Дональдом Кнутом, я считаю, что в разработке программного обеспечения есть очень важный элемент творчества, который, так же как и строительство мостов, позволяет объединить группу людей для создания чего-то прекрасного. Возможная аналогия с разработкой программного обеспечения – это строительство мостов, где мы до сих пор не четко осознаем все процессы стоящие за процессом строительства.
I guess the question is, is it possible to create a discipline of software engineering that is as effective as the other engineering disciplines? If we use the chemical engineering metaphor, where are we in the time line of understanding the underlying science and applying it to our process? Perhaps we are at the equivalent point to the mid to late 1800s but I very much doubt the years will map linearly, it’s probably more like an exponential mapping. The elusive software engineering is probably its own entity, are our metaphors confining our thinking and hindering our ability to objectively look at this problem?
Вопрос здесь в том, можем ли мы создать дисциплину, изучающую разработку программного обеспечения, и не уступающую по эффективности другим дисциплинам? Если использовать метафору химического производства, то где мы находимся сейчас на пути понимания самой науки и ее внедрения в процесс? Исходя из такого сравнения, возможно, мы находимся где-то в начале или в конце 19 века, но я очень сомневаюсь, что шкала времени тут имеет линейный характер и скорее всего эта шкала развития будет больше похожа на экспоненту. А возможно, разработка программного обеспечения – это отдельная сущность, и наши метафоры сдерживают наше мышление и препятствуют объективно взглянуть на реальность?
The software industry is also different from almost any other technical industry in history, just in the sheer number of people who now participate in it worldwide and it seems that the barriers to enter the field can be lower than that of other engineering and scientific disciplines in regards to formal degrees.
Индустрия разработки программного обеспечения отличается, практически, от любой другой известной нам технической индустрии, учитывая огромное количество людей участвующих в разработке программного обеспечения по всему миру, и кажется, что порог вхождения в эту область деятельности может быть ниже, чем у других инженерных дисциплин, и в соответствии с официальными научными степенями.

A: We Are Developers!
Ответ: Мы – Разработчики!

Оригинал текста: Q:Are we not engineers?
Автор оригинального текста: Geoff Moes, архитектор программного обеспечения и Java разработчик
Перевод: Дмитрий Жарий

среда, 6 апреля 2011 г.

Five signs that your talents are not appreciated

Here are the five signs:
Вот пять признаков:
  1. Late arrival to the office. Your boss is so blind to see your great contributions to the company, therefore you are so de-motivated that you come in to the office late everyday.
    Поздний приход на работу. Ваш начальник настолько слеп, что просто не замечает ваш колоссальный вклад в развитие компании, именно поэтому вы настолько демотивированы, что приходите на работу поздно каждый день.
  2. Micro-management. Your boss is always trying to micro-manage you by telling you the “right” ways to do things such as agile methodologies, but actually you know those aren’t just good as your way because you’ve been in the trenches long before your boss.
    Микроменеджмент. Начальник все время пытается контролировать каждое ваше действие, указывая вам «правильный» путь, как нужно «это» делать правильно по гибким методологиям, но, на самом деле вы знаете, что этот «правильный» не так уж хорошо, потому что опыта у вас больше, чем у вашего начальника.
  3. Rejecting your good suggestions. You have been pushing a complete conversion to a cutting edge technology to double the productivity of the team, but your boss just won’t listen.
    Ваши лучшие предложения отвергаются. Вы настаиваете на полном преобразовании рабочего процесса и переходе на передовые технологии, чтобы удвоить производительность команды, но, ваш начальник просто не хочет об этом слышать.
  4. Incompetent peers. Your peers are so incompetent and have been hampering the product launch. Even though you have been telling them their problems, they just don’t get it.
    Ваши коллеги некомпетентны. Коллеги настолько некомпетентны, что это просто препятствует запуску продукта. Даже когда вы пытаетесь указать им на их проблемы – они этого просто не понимают.
  5. Being blamed. Your peers are so jealous of your great abilities that they try to isolate you and blame you for everything that has gone wrong.
    Вас обвиняют. Коллеги настолько завидуют вашим способностям, что пытаются изолировать вас и винить за все, что пошло не так.
These signs seemingly indicate that people aren’t appreciating your talents, but the fact is you may be just living in your own little world and will probably be fired in a few months! The truth that you may not be understanding right now is:
Все эти признаки, казалось бы, показывают на то, что люди просто недооценивают ваш талант, но, с другой стороны, может оказаться так, что вы просто живете в своем маленьком мирке, и скорее всего, вас могут уволить через несколько месяцев! Вот правда, которую вы можете просто не понимать сейчас:
  1. Late arrival to the office (Lack of commitment). Even if you aren’t happy with your job or the way you’re treated, you should still demonstrate your commitment to your duties. Arriving late is an obvious way to say that you have no commitment.
    Поздний приход на работу (Отсутствие загруженности). Даже если не удовлетворены своей работой или отношением к вам, вы все равно должны показать то, что вы загружены исполнением своих обязанностей. Поздний приход – это очевидный способ показать, что вы незагружены ничем.
  2. Micro-management (Not accepting advise for improvement). Seeing the difficulties you face, your boss is trying to help you by giving you good advice. But you are so attached to your ego and stubborn to see any values in any new approaches.
    Микроменеджмент. (Невосприятие советов по улучшению). Видя трудности, с которыми вы сталкиваетесь, начальник пытается помочь, дав хороший совет. Но, вы так увлечены своим эго, что просто не хотите видеть ценность в любом новом подходе.
  3. Rejecting your good suggestions (Not understanding the priorities of the company). Your suggested technology may seem great to yourself, but actually it may be just too premature or is not among the top priorities of the company. Everyone is trying to tell you that but you just won’t listen.
    Ваши лучшие предложения отвергаются (Непонимание приоритетов компании). Предлагаемая технология, может быть, и выглядит очень хорошей, но только для вас, а на самом деле, это предложение может оказаться слишком преждевременным и не входить в число главных приоритетов компании. Все пытаются сказать вам это, но вы просто не хотите слушать.
  4. Incompetent peers (Destroying harmony). You may be good or not, but it is never a good idea to pick the mistakes of others. You will appear like an asshole to all your peers. Instead, you should help others improve.
    Ваши коллеги некомпетентны (Разрушение слаженной работы). Вы можете быть хороши или плохи, но, никогда не придирайтесь к ошибкам других. Ваши коллеги будут считать вас мудаком. Вместо этого, просто помогите вашим коллегам улучшить их работу.
  5. Being blamed (Not seeing your own mistakes). Be brave and admit it, those mistakes were yours. If you don’t see your own mistakes, you’ll never grow.
    Вас обвиняют. (Невидение собственных ошибок). Будьте смелым и признайте, что эти ошибки были вашими. Если вы не видите собственных ошибок – вы никогда не вырастите.
Fortunately, it is not too late to realize your own mistakes. Stop denying and you’ll have a much brighter future.
К счастью, еще не поздно осознать ваши собственные ошибки. Прекратите их отрицать, – и ваше будущее будет намного светлее.
Автор заметки: Kent Tong
Оригинал: Five signs that your talents are not appreciated
Перевод: Дмитрий Жарий

воскресенье, 27 марта 2011 г.

What is your developer's position?

"I seek Senior Developer position" - something like this begins Objective section in most CVs. The point is not that a company is looking for a developer precisely on such position and that the developer appreciated not only themselves but also other developers of this company, when he wrote his CV. In today post we will describe how to make this assessment developers and recruiters.
Я ищу работу на позицию Старшего Разработчика – как то в таком духе начинается графа Цель в большинстве резюме. Дело тут не только в том, что компания ищет разработчика именно на эту должность, а скорее в том, что разработчик, со своей стороны, оценил не только себя, но и других разработчиков компании, когда составлял резюме. В сегодняшнем посте, я хотел бы рассмотреть то, как делают такую оценку разработчики и рекрутеры.

The first thing we'll do is to decide who's who:
Для начала, давайте определимся, кто есть кто:

  • Junior Developer – 75% of his work should be controlled by team lead;
    Младший Разработчик – 75% его работы должен контролировать Тимлид;
  • Intermediate Developer – 50% of his work should be controlled by team lead;
    Разработчик Среднего Уровня (Intermediate Developer) – 50% его работы контролирует Тимлид;
  • Senior Developer – 25% of his work should be controlled by team lead;
    Старший разработчик – 25% его работы контролирует Тимлид;
  • Team Lead – 0% of his work should be controlled by team lead (only by project manager).
    Тимлид – 0% его работы контролирует Тимлид (отчитывается только Менеджеру Проекта)

Why does developer's position depend? Many said it was determined the knowledge, skills, experience, certifications, ability to solve tasks quickly and qualitatively, etc. It is also important previous job because the developers are trying to take a step up. But there is another side - a common level compared with other developers.
От чего зависит должность разработчика? Многие определяют это знаниями, опытом, сертификациями, умением решать задачи быстро и качественно и т.д. Но, так же важна и предыдущее место работы, потому что разработчики пытаются подняться вверх в карьерном и материальном смыслах. Но, есть и другая сторона – общий уровень по сравнению с другими разработчиками.

Assume that the developer is working on the Intermediate Developer position in medium-sized company in non the largest city and has choices:
Предположим, что разработчик работает на позиции Intermediate Developer в компании среднего размера в не самом крупном городе, и у него есть выбор:

  • Be Team Lead;
    Стать Тимлидом;
  • Be Senior Developer;
    Стать Старшим Разработчиком;
  • Be Junior Developer.
    Стать Младшим Разработчиком

Version of "Think up a brilliant idea, start a startup and take over as Team Lead or Program Manager (often all at once)" we will not consider because a topic for another discussion.
Версию «Придумать гениальную идею, создать свой стартап и взять на себя обязанности Тимлида или Менеджера Проекта (или все сразу)»мы не будем рассматривать, поскольку это тема для отдельного разговора.

I think you are a bit surprised that Intermediate Developer can take virtually any position!
Я думаю, вы немного удивлены тем, что Intermediate Developer может занять практически любую должность!

The script for the Team Leader may be next : developer starts to work hard on their knowledge and skills. I.e. he examines the challenges, attend conferences at international level, responds to the forums, gets a professional blog, writes articles in journals, actively participates in user groups, passes certification, creates open source project. The developer becomes a famous person at the level of his country. After this chance to become a Team Leader in the current and similar companies are greatly increased.
Сценарий для Тимлида может быть следующим: разработчик начинает усиленно работать над своими знаниями и навыками. Он исследует различные проблемы, участвует в различных конференциях международного уровня, отвечает на форумах, ведет профессиональный блог, пишет статьи для журналов, активно участвует в собраниях пользовательских групп, проходит сертификации, создает проект с открытым исходным кодом. Разработчик становиться известным человеком на уровне своей страны. После этого, его шанс стать Тимлидом в текущей или аналогичной компании существенно увеличивается.

With the Senior Developer is much easier. If the developer is not lazy, he gradually grows to Senior Developer. It is only a matter of time and effort that makes this developer.
В случае со Старшим Разработчиком все значительно проще. Если разработчик не ленивый, то он постепенно вырастает до позиции Старшего Разработчика. Это лишь вопрос времени и усилий, которые прилагает разработчик.

We turn to the most interesting part - how to turn from a Intermediate Developer to Junior Developer! No, it does not need to do nothing at work. Then you just get fired (do not say that I did not warn you)... One of the possible ways to get back Junior Developer is to get a job at a big foreign company. If the above-mentioned developer does not live in the U.S. and wants to go to Microsoft, for example, the command to Phil Haack, then the chance that it will take on the Intermediate Developer position is very small.
Мы подошли к самой интересной части, о том, как Средний Разработчик (Intermediate Developer) может стать Младшим Разработчиком! Нет, для этого не нужно ничего делать на вашей работе! Иначе вас просто могут уволить (и потом не говорите, что я вас не предупреждал) … Один из способов вернуться на позицию Младшего Разработчика – это получить работу в большой иностранной компании. Если вышеупомянутый разработчик не проживает в США, и хочет перейти в Microsoft, например, в команду Фила Хаака, то вероятность того, что он будет претендовать на должность Intermediate Developer – очень мала.

Only one conclusion - you need to always correctly assess your level in relation to those developers with whom you have to work.
Вывод напрашивается один: вам необходимо всегда правильно оценивать свой уровень по отношению к тем разработчикам, с которыми вы будете работаете.

The obvious question is how to assess the level of future colleagues?
Очевидный вопрос: как оценить уровень будущих коллег?

In case the commands that produce a public product and have an active web life, it's easy enough. For private teams I recommend to explore a public web site or can download a trial version of the product.
В случае команд, которые создают общеизвестные продукты и ведут активный образ жизни в Сети – это достаточно просто. Для непубличных команд, я рекомендую исследовать веб-сайт их компании или, по возможности – скачать пробную версию их продукта.

So, you write a CV to a specific position. At this point, I'm sure you've done it more than comprehended. But, unfortunately, usually the company interviews several employees at one workplace. There are cases where developers have come to the position below. For example, Senior Developer has reached the Team Leader level but sends a CV to the Senior Developer position. For it there are many reasons:
Итак, вы пишете резюме на конкретную позицию. На данный момент, я уверен, что вы делаете это более осмысленно. Но, к сожалению, как правило, компании интервьюируют нескольких человек на одно рабочее место. Бывают случаи, когда приходят на должность ниже текущей. К примеру, Старший Разработчик достиг должности Тимлида, но отправляет резюме на должность Старшего Разработчика. И на это есть множество причин:

  • The company does not have the Team Leader position at the moment;
    В данный момент у компании нет вакантной должности Тимлида;
  • The developer is afraid of accountability in higher position;
    Разработчик боится ответственности на более высокой должности;
  • The applicant clearly underestimates himself.
    Кандидат четко недооценивает себя.

Bad recruiter immediately take the candidate on the current position. The motivation:
Плохой рекрутер немедленно примет кандидата на текущею позицию. Мотивация такая:

  • Potentially reduce the price / quality ratio;
    Возможность сократить соотношения цена / качество
  • To stimulate other team members to improve their knowledge;
    Стимулирует других членов команды на улучшение их знаний
  • Eliminates the need to listen to other candidates.
    Устраняет необходимость выслушивать других кандидатов

A good recruiter will try to find a suitable place for this candidate. Perhaps in a related team. He can even deny him the following reasons:
Хороший рекрутер постарается найти подходящее место для этого кандидата. Возможно и в другой команде. А может даже отказать кандидату, исходя из следующих причин:

  • The team must work as a harmonious mechanism. And if one wheel more than others it iss possible failure of this mechanism;
    Команда должна работать как слаженный механизм. И если одно колесо больше других, то это может быть причиной возможного сбоя всего механизма;
  • The man who takes his place sooner or later to change it. Well, if it is within the team. In our case, there will be a new project where he can try himself;
    Человек намерен рано или поздно сменить занимаемое место. Возможно, занять другое место в команде. В нашем случае, скоро откроется новый проект, где он может испытать свои силы;
  • Need to find the best from Senior Developers, but not a Team Leader from Senior Developers.
    Необходимо найти лучшего среди Старших Разработчиков, но не Тимлида среди Старших Разработчиков.

Of course, the division into good and bad recruiter is conditional and depends on the company's goals and current status.
Конечно же, разделение на «хорошего» и «плохого» рекрутера является условным и зависит от целей компании и текущей обстановки.

Most often, however come the developers who have not reached an expected level. What to do with them? Again, try to look at the situation in different eyes. Bad recruiter doesn't just hire candidate. Good one asks yourself the following questions:
Однако, чаще всего приходят разработчики, которые еще не достигли ожидаемого уровня. Что делать с ними? Опять же, взгляните на эту ситуацию с разных сторон. Плохой рекрутер просто не наймет кандидата. Хороший задаст себе следующие вопросы:

  • Can we teach him? Does the company time and money now is it? (definetly, it is an option for Junior Developer. In practice, staff were grown on their own is the best);
    Можем ли мы обучить его? Можно ли затратить время и деньги компании на это? (Безусловно, это вариант для Младшего Разработчика)
  • Can we retrain him? (for example, ASP.NET Intermediate Developer decided to try out for Silverlight Intermediate Developer. It is important that people do not have to completely relearn from scratch);
    Можем ли мы его переподготовить? (к примеру, ASP.NET Intermediate Developer, решил стать Silverlight Intermediate Developer. Важен тот факт, что человек уже владеет множеством навыков и нет необходимости готовить его с нуля)
  • Can we find someone better for a given time? (deadlines, no comments).
    Можем ли мы найти кого-нибудь лучшего в данный момент времени (подошел дедлайн для проекта, без комментариев)

See the difference? Bad recruiter solves the problem fast and straightforward, good recruiter solves the problem efficiently and in the future.
Чувствуете разницу? Плохой рекрутер решает проблему быстро и просто, хороший рекрутер – эффективно с взглядом на будущее.

I hope that convinced you that the developer's position is not always easily determined. But if you're the developer, please to define it for your next job more clearly.
Надеюсь, что я убедил вас в том, что позицию разработчика не всегда легко определить. Но, если вы разработчик, пожалуйста, определите ее для вашего следующего места работы более четко.


Автор текста: Oleg Smirnov
Оригинал текста: What is your developer's position?
Перевод: Дмитрий Жарий

суббота, 19 марта 2011 г.

6 Words That Make Your Resume Suck

This article is part of a series called How to Write a Resume. To start this series from the beginning, read the introduction.

Эта статья – часть серии «Как написать резюме». Чтобы начать серию сначала, прочитайте введение.

I’ve used a few bad words in my life. S$it, you probably have too. But when the wrong words appear on your resume, it sucks.

За свою жизнь, я использовал несколько плохих слов. Даю %^й на отсечение, что вы тоже делали это. Но, когда неправильные слова появляются у вас в резюме – это делает его отстойным.

These sucky words are not of the four-letter variety. These words are common. They are accepted. They litter the average resume with buzzword badness. Hiring managers can identify sucky words in seconds, leaving your resume work worthless.

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

So how do you write a wicked resume without the suck? How do you turn the wrong words into right? To help you land the job interview, here’s how to spin the 6 sucky resume words into skills that sizzle.

Как же написать замечательное резюме без словесного отстоя в нем? Как превратить слова из неправильных в правильные? Для того, чтобы вы получали приглашения на собеседование, далее, я покажу как превратить 6 отстойных слов в навыки, которые будут говорить за вас.

1. Responsible For
1. Обязанности


My lips pucker and make sour sucking noises when I read “Responsible For” on a resume. Of course you’re responsible for something. But how many? How long? Who? What? When? Rather than waste the hiring manager’s time reading a vague list of responsibilities, be specific and use quantitative figures to back up your cited skills and accomplishments.

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

Employers want the numerical facts. Write percentages, dollar amounts, and numbers to best explain your accomplishments. Be specific to get the point across quickly. Prove you have the goods to get hired.

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

BAD
Responsible for writing user guides on deadline.
Плохой пример:
Был ответственен за создание инструкций для пользователей перед сдачей проекта


GOOD
Wrote six user guides for 15,000 users two weeks before deadline.
Хороший:
Написал шесть инструкций для 15 000 пользователей за две недели до сдачи проекта


BAD
Responsible for production costs.
Плохой:
Был ответственен за управление себестоимостью продукции.


GOOD
Reduced production costs by 15 percent over three months.
Хороший:
Сократил себестоимость продукции на 15 процентов в течении трех месяцев.


The resume that avoids vague “responsibilities” and sticks to facts detailing figures, growth, reduced costs, number of people managed, budget size, sales, and revenue earned gets the job interview.

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

2. Experienced
2. Навыки и опыт


Are you experienced? Sexy. Rather than cite Jimi Hendrix on your resume, pleeease just say what your experience entails. Saying you’re experienced at something and giving the facts on that experience are two very different approaches.

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

BAD
Experience programming in PHP.
Плохой пример:
Опыт разработки на PHP


GOOD
Programmed an online shopping cart for a Fortune 500 company in PHP.
Хороший:
Разработал электронную корзину покупателя для компании Fortune 500 на PHP


Hiring managers want to know what experience, skills, and qualifications you offer. Do tell them without saying, “I am experienced.”

Менеджеры по найму персонала хотят детально знать, какой именно опыт, навыки и квалификацию вы предлагаете. Скажите это им, не произнося фразы «Опыт работы с…»

3. Excellent written communication skills
3. Превосходные навыки письменного общения


Yes, I realize this isn’t a single word but rather a phrase. This phrase must die. It’s on most resumes. Is it on yours?

Да, я понимаю, что это не одно слово, а скорее, целая фраза. И это фраза должна подохнуть. Она ваша?

BAD
I have excellent written communication skills.
Плохой пример:
Владею превосходными навыками письменного общения


GOOD
Wrote jargon-free online help documentation and reduced customer support calls by 50 percent.
Хороший:
Написал контекстную справку по приложению, и тем самым добился снижения количества обращений в службу поддержки клиентов на 50 процентов.


If you’ve got writing skills, do say what you write and how you communicate. Are you writing email campaigns, marketing materials, or user documentation? Are you word smithing legal contracts, business plans, or proposing proposals? However you wrap your words, be sure to give the details.

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

4. Team Player
4. Командный игрок


Are we playing baseball here? Unless you want to be benched with the other unemployed “team players” then get some hard facts behind your job pitch.

Вы пришли сюда в баскетбол играть? Если не хотите сидеть на лавке запасных с другими безработными «командными игроками», то не забудьте указать факты из вашей прошлой деятельности.

BAD
Team player working well in large and small groups.
Плохой пример:
Хорошо работаю в команде в больших и малых коллективах


GOOD
Worked with clients, software developers, technical writers, and interface designers to deliver financial reporting software three months before deadline.
Хороший:
Работал с клиентами, разработчиками, техническими писателями и дизайнерами пользовательского интерфейса для завершения проекта по финансовой отчетности за три месяца до запланированного срока сдачи.


If you want to hit a home run then do explicitly say what teams you play on and qualify the teams’ achievements.

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

5. detail oriented
5. Педантичный


What does detail oriented mean? Give the specifics to the details with which you are oriented. Please, orient your reader to the details.

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

BAD
Detail oriented public relations professional.
Плохой пример:
Профессионал по продвижению, умеющий концертировать внимание на деталях.


GOOD
Wrote custom press releases targeting 25 news agencies across Europe.
Хороший:
Создавал различные пресс-релизы, разосланные в 25 информационных агентств по всей Европе.


If you have the details, do share them with the hiring manager. Give the facts, the numbers, the time lines, the dollar figure, the quantitative data that sells your skills and disorients the competition.

Если у вас на руках есть конкретика, поделитесь ею с менеджером по найму персонала. Покажите факты, цифры, сроки, денежные суммы и все те данные, которые помогут продать ваши навыки и обогнать конкурентов.

6. Successful
6. Успешно


Hopefully you only list the successes on your resume. So if everything is a success, then why write the s-word? Stick to showing your success by giving concrete examples of what you’ve done to be successful! Let your skills, qualifications, and achievements speak for you.

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


BAD
Successfully sold the product.
Плохой пример:
Успешно продал продукт.


GOOD
Increased sales of organic chocolate by 32 percent.
Хороший:
Увеличил продажи органического шоколада на 32 процента


When it comes to your successes, please don’t be shy. Boast your best, sing your praises, and sell your skills.

Когда речь заходит о ваших успехах, пожалуйста, не стесняйтесь. Покажите себя с лучшей стороны, воспевайте себе хвалу и продавайте ваши навыки.

Final Words
В заключение


There you have it. Six of the suckiest words (or phrases) commonly found on resumes today. By focusing on the facts, detailing the details, and qualifying your qualifications you may just land yourself the job interview.

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


Англоязычный оригинал статьи: 6 Words That Make Your Resume Suck
Перевод: Дмитрий Жарий

воскресенье, 13 марта 2011 г.

Farata Systems: Running the company for 5 years. The lessons learned.

Five years ago three seasoned software developers created a new company and called it Farata Systems. Fa was taken from Fain, Ra is from Rasputnis, and Ta from Tartakovsky. Five years is a good milestone for any firm, and in this article I’ll tell you our story.

Пять лет назад, трое бывалых программистов создали новую компанию и назвали ее Farata Systems. Fa было взято из фамилии Fain, Ra из Rasputnis, и Ta из Tartakovsky. Пять лет – это значительный этап для любого бизнеса, и в этой статье я расскажу нашу историю.

When people create a startup, they often have a big idea, sometimes a business plan and an exit strategy (typically, to be acquired by a larger company for an X amount of money). But was Farata a startup in the first place? Here’s the quote from Wikipedia:

Когда люди создают стартап, у них часто есть значительная идея, иногда бизнес-план и «стратегия выхода» (как правило, быть приобретенным крупной компанией за N-ю сумму денег). Но, была ли Farata стартапом изначально? Вот цитата из Википедии:

The phrase "startup company" is often associated with high growth, technology oriented companies. Investors are generally most attracted to those new companies distinguished by their risk/reward profile and scalability. That is, they have lower bootstrapping costs, higher risk, and higher potential return on investment. Successful startups are typically more scalable than an established business, in the sense that they can potentially grow rapidly with limited investment of capital, labor or land. Startups encounter several unique options for funding. Venture capital firms and angel investors may help startup companies begin operations, exchanging cash for an equity stake.

Фраза «стартап-комания» часто связывают с бурно растущими, высокотехнологичными компаниями. Инвесторов, как правило, больше всего привлекает в этих компаниях соотношение риска и прибыли и расширяемость. Затраты на запуск стартапа ниже, риски – выше, но и потенциальная окупаемость инвестиций – выше. Успешные стартапы, как правило, более расширяемы, чем налаженный бизнес, в том смысле, что, потенциально, они могут расти быстрей с ограниченными инвестициями в бюджет, рабочую силу и занимаемую территорию. Стартапы поддерживают несколько уникальных способов финансирования. Венчурные предприятия и Бизнес-ангелы могут помочь стартапам начать свою деятельность, обменивая денежные средства на эквивалентное количество акций.

We didn’t have any investors. We were profitable from day one by working as billable consultants for corporate clients. We didn’t have any business plan. We had our own software, but it brought us peanuts in terms of monetary rewards. We didn’t have money to invest into finding a professional salesman to offer our skills to potential new clients. We didn’t have any exit strategy. We didn’t even have an elevator pitch to quickly explain what are we doing. What did we have and why did we create this company?

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

We had good noses. It was the time when Adobe acquired Macromedia and released a software product for development of Rich Internet Applications (RIA). The name of the product was Flex, and even though its first version has been created earlier, Adobe made some smart marketing changes to make it affordable. We decided to bet on this product. We started with writing technical articles and blogs about Flex - in early 2006 there were no or little information available on the subject. Then we wrote an advanced book on bringing together Flex and Java in the enterprise world.

У нас был хороший нюх. Это было то время, когда Adobe приобрела компанию Macromedia и выпустила продукт для разработки Насыщенных Интернет Приложений (RIA). Название продукта было – Flex, и не смотря на то, что его первая версия была создана ранее, Adobe сделала несколько умных маркетинговых ходов, чтобы сделать Flex доступным. Мы решили сделать ставку на этот продукт. Мы начали с создания технических статей и публикаций в блогах о Flex; в начале 2006 года информации по этой теме не было вообще, или было очень мало. После, мы написали книгу о том, как связать вместе Flex и Java в области разработки корпоративных приложений.

Each of us had billable hours (and the rates were pretty high), but we also started bringing other people on board and offering their service to our clients. How can you sell a consultant to any company without having a salesforce? We did it by PR. Consistent writing of quality technical materials and speaking at various gatherings (from 5 people in a local user’s group to large audiences at major conferences) got the word out - we started getting requests for help in development of enterprise RIA. Using the terminology from software engineering, we’ve implemented the Inversion of Control design pattern, which is also known as a Hollywood Principle: “Don’t call us, we’ll call you”. We were patiently waiting till someone would call us.

У каждого из нас были оплачиваемых часы (и почасовые ставки были довольно высокими), но мы также начали нанимать новых людей и продавать их услуги клиентам. Вы спросите, как можно продать услуги консультанта любой компании, не имея отдела по продажам? Мы делали это при помощи пиара. Постоянная публикация качественных технических материалов и выступлениях на различных собраниях (от 5-ти человек в местной группе пользователей, до широкой аудитории на крупных конференциях) сделали свое дело – мы начали получать просьбы о помощи по разработке корпоративных RIA приложений. Говоря на языке программистов, мы реализовали паттерн проектирования Инверсия Управления, или как говорят на Голивудщине: "Не звоните нам, мы вам сами позвоним".

But publishing advanced technical materials was a double-edged sword. While perspective clients knew that Farata’s experts can be engaged for solving heavy-duty tasks, other consulting companies were simply placing their inexpensive consultants on never-ending enterprise projects.
First, we started getting requests for help only with non trivial situations, for example,
- we are going live with our online game in a month, but when more than two people are playing they experience serious slowdowns
- our enterprise application works fine, but once in a while some users are losing messages
- you don’t need to sell us Flex, we know it’s good for UI, but can you improve the reliability and customize communication protocols to fit our needs
- we’ve chosen Flex to avoid page refreshes, but our pilot application requires 40 seconds just to load the first page

Но, публикация продвинутых технических материалов была палкой о двух концах. С одной стороны, клиенты знали, что эксперты из Farata могут успешно решить трудные задачи, с другой стороны, конкурирующие консалтинговые компании размещали своих недорогих консультантов на «вечные» корпоративные проекты.
По началу, мы начали получать просьбы о помощи только по нетривиальным ситуациям, для примера: «наша компания собирается выпустить онлайн-игру через месяц, но, когда в нее играют более двух человек, то пользователи ощущают серьезные замедления в работе»,
«наше корпоративное приложение работает хорошо, но, иногда некоторые пользователи теряют свои сообщения»
«Вам нет необходимости продавать нам Flex, мы знаем, что он хорошо для пользовательского интерфейса, но можете ли вы усовершенствовать надежность приложения и настроить протоколы взаимодействия для того, чтобы приложение соответствовало нашим потребностям?»,
«Мы выбрали Flex чтобы избежать перезагрузки страниц, но наш пилотный проект требует более 40 секунд только для загрузки стартовой страницы».


We were helping everyone, but didn’t grow much. Placing a couple of consultants on a project at a large company was fine, but it wasn’t a major change from the growth perspective.
At some point, we started getting requests for bidding on projects. If a large corporation was about to start a large project, they’d ask several small vendors to bid on it. We’d sign a non-disclosure agreement to receive a Request For Proposal. Being experienced architects from our past lives, we could properly estimate the efforts required for successful completion of the project in question. We could foresee the issues and warn the perspective client about them. But we were not experience bidders – we were telling the truth.

Мы помогали всем, но рост был небольшим. Устройство нескольких консультантов на проекты в крупные компании было делом хорошим, но это не открывало огромных перспектив для роста.
И в какой-то момент мы начали участвовать в тендерах по разработке проектов. Если крупная компания собиралась начать новый проект, они приглашали нескольких небольших компаний по разработке для участия в тендере. Мы были готовы подписать документы о неразглашении информации ради того, чтобы получить заявку на разработку проекта. Будучи опытными архитекторами, мы могли точно оценить все усилия, необходимые для успешного завершения рассматриваемого проекта. Мы могли предвидеть проблемы и предупредить потенциального клиента о них. Но, игроками на тендерах были неопытными – мы говорили правду.


For example, once we gave a $250K estimate for a project, while our competitors offered to do the same job for $50K. Now we know - they applied such strategy just to get their foot in the door and to win the bid. Six months down the road we’d get a call from the project manager of that corporation complaining that the promised $50K turned into $500K and the project arrived to the dead end. Interestingly enough, we didn’t learn anything from that lesson. If we believe that the project would cost $250K, we’ll say so. But now we also offer to reduce the scope if there is a shortage of funds.

Однажды, мы оценили проект в 250 тысяч долларов, в тоже время, наши конкуренты предложили сделать работу за 50 тысяч долларов. Теперь-то мы знаем, что они применили такую стратегию для того, чтобы просунуть ногу в закрывающуюся дверь и выиграть тендер. Через шесть месяцев после тендера, мы получили звонок от менеджера проекта той компании, жалующегося на то, что $50 тыс. превратились в $500 тыс., а проект оказался в тупике. Любопытно, но мы ничему не научились после того случая. Мы верим в то, что если стоимость проекта $250 тыс, то следует назвать именно эту сумму. Но теперь, мы предлагаем урезать объем работ при нехватки средств.

Coming back to promoting ourselves, I’d like to tell you about the role of technical training in our growth. Two of us are Adobe Certified Instructors and all these years we were teaching classes to corporate clients. Adobe develops excellent courseware and we use it a lot. But we also found a niche that was not taken by anyone. We became the only company that started offering advanced custom curriculum in developing rich Internet application with Flex and Java. As an example, during the last two years we were teaching public zero-marketing technical seminars in New York, Boston, Toronto, London, Moscow, Brussels. These seminars didn’t make us rich even though we remain in the positive cash territory, but they gave us a chance to spend two-three days in front of fellow developers proving that we are technically sound. You can’t BS for two days in a room filled with programmers. Have you ever had to go through a technical job interview that lasted two full days? No? We do it on a regular basis.

Возвращаясь к нашему промоушену, я хотел бы рассказать о роли технических тренингов для нашего развития. Двое из нас – тренеры, сертифицированные Adobe, и все это время мы проводили обучение для корпоративных клиентов. Adobe разрабатывает отличные курсы, которыми мы пользовались множество раз. Но, мы также обнаружили нишу, незанятую никем. Мы стали единственной компанией, которая предлагала расширенные программы по разработке Насыщенных Интернет Приложение в связке Flex + Java.
На протяжении последних двух лет, мы проводили недорогие публичные технические семинары в Нью-Йорке, Бостоне, Торонто, Лондоне, Москве и Брюсселе. Семинары не сделали нас богатыми, хотя и приносили прибыль, но они давали на шанс провести несколько дней среди группы разработчиков, демонстрируя свои технические навыки. Вы не сможете городить чушь в течение двух дней в комнате, заполненной профессиональными разработчиками. Вам когда-либо приходилось проходить техническое интервью, которое длилось на протяжении целых двух дней? Нет? Мы делаем это регулярно.


These public training events are like technical interviews for us and usually we receive a call or two from our former students, “Guys, we need help with our project”. This can be a year after we met, but hey, it’s better late than never.

Эти публичные тренинги, как интервью для нас, и обычно мы получаем один-два звонка от наших бывших студентов, со словами: "Ребята, нам нужна помощь с нашим проектом". Это бывает даже через год после нашей встречи, но, лучше поздно, чем никогда.

At some point we won a large project (no, we didn’t lie in the proposal). How thin can you spread three experienced consultants? We couldn’t be at the same time in three different places. We had to bring more people on board to make a profit and do the job. An hourly rate we’re getting from our clients minus some profit margin would be the rate that we could offer our consultants.
Between 2006 and 2008, consulting rates offered for RIA development have substantially decreased. It became difficult to charge premium even for the expert-grade services, and we switched to a blended rate model. If someone needs a senior developer with Flex/Java skills, we offer a resource (hate this word but this is what the industry understands) that consists, say, from 10% of myself (or one of my partners) located here in the USA and 90% of a developer working from Eastern Europe.

Однажды, мы выиграли крупный проект (нет, мы не соврали в заявке на него). Как можно было распределить усилия троих опытных консультантов? Мы не могли быть одновременно в трех разных местах. Нам было необходимо нанять новых людей, чтобы получать больше прибыли и делать больше работы. Нашим консультантам мы могли предложить почасовую ставку, оговоренную с нашим клиентом, вычитая суму на рентабельность нашей компании.
В период между 2006 и 2008 годом, ставки консультантов в сфере RIA разработки существенно снизились. Стало сложно получать оплату даже по услугам экспертного уровня, и мы перешли на смешанную модель ставок. Если кто-либо нуждался в старшем разработчике с навыками Flex/Java, мы предлагали этот ресурс (ненавижу это слово, но его хорошо понимает индустрия), которая состояла из 10% моего времени (или времени одного из моих партнеров), находящегося в США и 90% времени разработчика из Восточной Европы.


This model works well for us. This gives peace of mind to our clients who know that their project is in good technical hands while staying within the budget. Such outsourcing model works because we (as opposed to large corporations) cherry pick each and every developer we hire from overseas. Today, 25-30 people work on Farata’s projects.

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

We’ve also learned that for a small company, selling programming tools for software developers is literally impossible. People want free stuff and they get it from us. We’ve open sourced a number of productivity tools that go under the name Clear Toolkit, which became yet another PR-tool for our company.

Мы поняли, что для небольшой компании, продажа программных инструментов для разработчиков, в буквальном смысле, невозможна. Люди хотят видеть инструмент бесплатным, и они получают его от нас. Мы открыли исходные коды немалое число инструментов, которые идут под названием пакета Clear Toolkit, который стал еще одним инструментом для раскрутки нашей компании.

On the other hand, we’ve created a spin-off startup Surance Bay that’s specializing in development of the software for insurance industry. Today, Farata serves as an investor (!) of that startup, which started bringing cash in a record time, but this can be a subject for another article.

С другой стороны, мы создали дочерний стартап Surance Bay, который специализируется на разработки программного обеспечения для страховой индустрии. Сегодня, Farata служит инвестором (!) этого стартапа, который начал приносить прибыль в рекордно короткие сроки, но, это уже может быть темой для отдельной статьи.

Two years ago, a top manager of a large company decided to create his own company. I knew the guy and he came to me asking for an advice on how to start a small business. While he didn’t have any experience of running a small company his background of running a large practice was obvious. He started with a business plan and a lot of financial calculations. He asked me, “Where are you guys planning to be in five years? How big are you planning to get? What kinds of revenues do you have in mind? What’s your exit strategy?” He was a very experienced manager and quickly realized that I was not ready to answer all these questions. Finally, he said, “Are you guys just created a company to build a nice life styles for yourself?”

Два года назад, топ-менеджер одной крупной компании решил создать свою собственную компанию. Я был знаком с этим человеком, и он пришел ко мне с просьбой дать совет, как начать малый бизнес. Хотя, у него не было опыта ведения малого бизнеса, его опыт работы с крупным бизнесом был очевиден. Он начал с бизнес-плана и множества расчетов. Он спросил меня: "Где вы, ребята, планируете быть через пять лет? Насколько крупными вы собираетесь быть? Какую прибыль вы планируете получать? Какова ваша стратегия выхода? ". Он был очень опытным менеджером, и быстро понял, что я был не готов ответить на все его вопросы. Наконец, он сказал: "Так вы, ребята, создали компанию для того, чтобы построить себе хорошую жизнь?"

He was right. Without knowing it, we wanted to have nice life styles while doing what we enjoy. Five years after I can tell you that we’ve achieved this goal. We still don’t have any exit strategy because we are not planning to exit. We are enjoying our lifestyles, developing cool software, helping our large and small clients in achieving their goals, we are writing books, teaching and learning, attending conferences, raising kids, traveling. What else to wish for? God bless America!

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



Яков ФайнАвтор оригинальной статьи: Яков Файн, программист, эксперт и консультант по технологиям Java и Adobe Flex. Ведущий тренингов, автор и соавтор нескольких книг. Известен в кругах Flex и Java разработчиков в разных странах мира. Известен широкому кругу слушателей по русскоязычным подкастам про США и проекту IT-тематики Радио Бермудский Треугольник.

Перевод текста: Дмитрий Жарий

вторник, 8 марта 2011 г.

О том, почему мы будем использовать HTML(5) вместо Silverlight

I recently had to research which UI technology would be the best choice for the applications that my client is going to build in the next couple of years. This is a .NET shop, so there are 2 major directions you could move into: standards-based web development, or Silverlight. When you have to recommend one over the other, you ideally want to be able to back up your choice with more than just some opinions. So we made a list of candidates and did a POC for each one. Then we came up with a list of criteria, grouped in a bunch of categories. The criteria were all assigned a weight, and we scored each of them for all candidates.

Недавно, я провел исследование о том, какая технология создания пользовательского интерфейса будет наилучшим выбором для приложений, которые собирается создавать мой клиент в следующие несколько лет. Мой клиент – это команда .NET разработчиков, а это значит, что двигаться можно в двух основных направлениях: разработка с использованием стандартных веб-технологий или Silverlight. Когда необходимо рекомендовать одну технологию на противовес другой, то, в идеале, выбор должен быть основан на чем-то большим, чем на нескольких мнениях. Мы создали список технологий-кандидатов. После чего, мы создали перечень критериев, связанных в категории. Всем критерием был назначен некоторый вес, и мы оценили каждую из них для всех технологий-кандидатов.

In this post, i want to go over the categories of criteria, and discuss our findings. I'm also going to share the spreadsheet so you can go through the numbers yourself. Depending on your needs or your opinions, you can change the weights and the scores and see how that affects the outcome. I removed some of the criteria that were specific to my client, but it didn't have a significant impact on the outcome. For this post, I also limited the candidates to ASP.NET MVC 3 in combination with the jQuery family (jQuery Core, jQuery UI and jQuery Mobile) and Silverlight.

В этой статье, я хотел бы пройтись только по категориям критериев и обсудить наши выводы. Я поделюсь детальной таблицей с данными, для того чтобы вы смогли исследовать результаты самостоятельно. В зависимости от ваших потребностей или вашего мнения, вы можете изменить вес и оценку, и посмотреть, как это повлияет на результат. Я удалил несколько критериев, которые были специфичны для моего клиента, но это не вызвало огромного влияния на результат. Для этой статьи, я также сократил количество технологий-кандидатов до ASP.NET MVC 3 в сочетании с семейством jQuery (jQuery Core, jQuery UI и jQuery Mobile) и Silverlight.

Here's a quick listing of the categories and some of their criteria (for the actual list, check the spreadsheet... the link is at the end of the post):
Вот неполный список категорий и некоторых критериев (детальный список находиться в Excel документе, ссылку на который вы найдете в завершении статьи):
  • User experience (compelling UI, accessibility, intuitive/ease-of-use, accessible from multiple devices, accessable from multiple platforms)
    Взаимодействие с пользователем (совершенство пользовательского интерфейса, доступность, интуитивность/простота в использовании, доступность с различных устройств, доступность из различных платформ)
  • Infrastructure (easy/flexible deployment, monitorability)
    Инфраструктура (легкость/гибкость развертывания, контролируемость)
  • Security (safe from XSS, CSRF)
    Защищенность (от XSS, CSRF)
  • Performance (server footprint, client-side resource usage, asynchronicity, UI responsiveness, initial load times)
    Производительность(потребление ресурсов сервера, потребление ресурсов клиента, асинхронность , отзывчивость пользовательского интерфейса, начальное время загрузки)
  • Code/Architecture (maturity, reusability of validation logic, simplicity, maintainability, flexibility, power, testability, i18n, feedback cycle, learning curve, potential efficiency, rapid application prototyping, readable URLs, extensibility)
    Код/Архитектура(завершенность, повторное использовании логики проверок, простота , затраты на поддержку, гибкость, потенциал, тестируемость, i18n, цикл обратной связи, порог вхождения в технологию, потенциальная эффективность, быстрое прототипирование, читабельные URL, расширяемость)
  • People (limits the number of required skills, mindshare, documentation, community support, commercial support)
    Люди (число необходимых навыков, необходимая доля внимания со стороны пользователей, документация, поддержка общественностью, коммерческая поддержка)
  • Strategic (future-proof, standards-compliant, differentiator, backing, vision)
    Стратегия(перспективность, соответствие стандартам, отличия, поддержка, виденье)
  • License (do we have access to the code?)
    Лицензия (у нас есть доступ к коду?)
  • Cost
    Цена
  • Tools (IDE support, availability of extra tools, free 3rd party component availability, commercial 3rd party component availability
    Инструменты (Поддержка со стороны IDE, наличие дополнительных инструментов, наличие бесплатных компонентов от сторонних разработчиков, наличие платных компонентов от сторонних разработчиков)
Depending on what you or your organization requires, some of these might not apply to you. Perhaps there are other criteria that you find important and that we missed. Nevertheless, i think this is a pretty comprehensive list which covers most of the factors that you need to think about when making this kind of decision.

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

This graph visualizes how both technologies scored, grouped by category:
Следующий график иллюстрирует оценку обоих технологий по категориям:

HTML 5 vs Silverlight by categories

I'm sure there are quite a few things about that image that surprise you. The first thing you might be thinking is "how can Silverlight score so badly when it comes to User Experience?". The answer to that is quite simple: if your users aren't using a desktop/laptop with Windows or OS X on it, there is no experience to be had at all. Users that require assistive technology are out of luck as well since accessibility support in Silverlight is still very poor. If you hold those factors into account, it really doesn't matter much that you can easily make Silverlight applications incredibly flashy (pardon the pun). Besides, most people get bored and annoyed with excessive animations rather quickly, so you're often better off not to overdo it. With that in mind, jQuery UI and HTML5 will easily meet your needs for that kind of stuff.

Я уверен, что довольно много вещей, которые удивили вас на этом графике. Первое, что вы могли подумать это: «Почему Silverlight был оценен так плохо в категории Взаимодействие с пользователем?» Ответ довольно прост: если ваши пользователи не работают с Windows или OS X, то у них нет возможности использовать Silverlight. Не повезет и пользователям с ограниченными возможностями, так как их поддержка в Silverlight не развита. Если принять во внимание эти факторы, уже не имеет большого значения то, что при помощи Silverlight, вы можете создать невероятно роскошные приложения. Кроме того, большинству людей довольно быстро надоедает чрезмерная анимация, так что лучше в этом деле не переусердствовать. Имея это ввиду, jQuery UI и HTML5 могут лучше удовлетворить ваши потребности.

Another area where Silverlight scores very poorly is the strategic department. The fact that it's not standards-compliant obviously hurts a lot here, but there's more to it than that. First of all, the mobile story (again) pretty much kills it. Android and iOS don't support it. We already know it's never going to work on iOS and as long as it doesn't work on iOS, Android has no reason whatsoever to provide support because Silverlight simply isn't important in the grand scheme of things to any of the important players. Microsoft hasn't even announced a Silverlight browser plugin for WP7 yet and who knows if it will? That means that Silverlight web applications aren't usable on any mobile device right now, except for slates running a full Windows OS which looks like its only a tiny portion of the market. Secondly, despite its original tagline of "Lighting up the web", it appears that Microsoft only has about 3 scenario's in mind where it still actively pushes Silverlight: internal business applications, video streaming and native WP7 development. While internal business applications are certainly a large part of what we're going to do in the next couple of years, we're also going to build things that are available publicly and to a large variety of people. Going with Silverlight for the internal applications and HTML(5) for the public-facing applications wouldn't be very cost-efficient either since that means we have to train our developers for both cases. And it wouldn't make much sense anyway since HTML(5) is a great fit for internal business apps as well.

Следующая область, где Silverlight был оценен очень плохо, это – Стратегия. Факт несоответствия стандартам, очевидно, наносит сокрушительный удар, но, есть и другие недостатки. Прежде всего, мобильные платформы наносят еще один сокрушительный удар. Android и iOS не поддерживают Silverlight. Мы знаем, что эта технология никогда не будет работать на iOS, и пока она не работает на iOS, у Android нет никаких оснований поддерживать Silverlight, просто потому что эта технология не играет никакой важной роли. Microsoft еще даже не анонсировала создание плагина для поддержки в браузерах Windows Phone 7, и никто не знает, дождемся ли мы этого. Это означает, что веб-приложения на Silverlight не доступны с любого портативного устройства, за исключением тех, которые поддерживают полную версию Windows и составляют небольшую долю рынка. Во-вторых, несмотря на свое первоначальный лозунг «Озаряя Интернет», получается, что в планах Microsoft всего 3 активно продвигаемые сценария: разработка внутренних бизнес-приложений, потоковое видео и создание приложений для Windows Phone 7. Хотя, создание внутренних бизнес-приложений и является тем, чем мы будем заниматься в ближайшие несколько лет, мы все же планируем создавать публичные приложение, доступные большому кругу пользователей. Работа с Silverlight для внутренних приложений и HTML (5) для общедоступных приложений выглядит не экономичной, поскольку мы будем вынуждены обучать наших разработчиков обоим направлениям. И это не будет иметь большого смысла, поскольку HTML (5) отлично подходит для внутренних бизнес-приложений.

But, as you can see, there are areas where Silverlight scores better than ASP.NET MVC 3 with jQuery. For instance, when it comes to Tools, you can't deny the fact that Visual Studio and Blend cover a lot of ground when it comes to the whole Silverlight developer experience. At the very least, you can mostly stick to your familiar integrated environment, whereas with standards-based web development, you're likely to spend some time in Firebug or Google Chrome's developer tools instead of sticking almost entirely with Visual Studio. I personally don't mind (at all actually) to use other tools than Visual Studio, but there are quite a few .NET developers who do prefer to stick with Visual Studio. Which brings me to the People category. The biggest benefit that Silverlight has over standards-based web development is that you only need to know C# and XAML. With standards-based web development, you have to know HTML, CSS, JavaScript and the language of your server-side technology, in this case also C#. This might impact your ability to find new developers so Silverlight does have sort of an advantage there. Though i'd argue that you're better off in the long term with people who are willing to step out of their comfort zone instead of clinging to what they know. From a security point of view, Silverlight also scores better because you don't really have to worry about common issues such as XSS, CSRF and other vulnerabilities that are common in web-development.

Но, как вы могли заметить, есть области, в которых Silverlight оценивается лучше, чем ASP.NET MVC 3 + jQuery. Например, по категории Инструменты, вы не можете отрицать тот факт, что Visual Studio и Blend удовлетворяют большую часть потребностей разработчика. По крайней мере, большую часть времени разработки и отладки вы будете проводить в вашей уже знакомой IDE, в то время, как при работе с стандартными веб-технологиями, вам будет необходимо провести некоторое время, используя Firebug или инструментов разработчика в Google Chrome, вместо того, чтобы делать практически всю работу в Visual Studio. И это приводит меня к обсуждению категории Люди. Наибольшим преимуществом Silverlight над веб-разработкой, основанной на стандартах, есть то, что все что вам необходимо знать – это C# и XAML. Для разработки, основанной на стандартах вам необходимо знать HTML, CSS, JavaScript и язык, на котором написано ваше серверное приложение, в данном случае, это также C#. И это может повлиять на вашу способность по поиску новых разработчиков, так что в некотором роде, у Silverlight тут есть преимущество.
Хотя, я хочу отметить, что, в долгосрочной перспективе, вам лучше работать с теми людьми, которые готовы выйти из зоны комфорта, чем с теми, которые цепляются за то, что они уже знают. С точки зрения безопасности, технология Silverlight также оценена лучше, так как вам не придется о таких общих проблемах, как XSS, CSRF и других уязвимостях общих для веб-разработки.


So we have 3 categories where Silverlight scores better than ASP.NET MVC3/jQuery but that's far from sufficient to close the gap. Based on the weights we assigned to the criteria, the maximum possible score is 732. ASP.NET MVC3 with jQuery scored 568. Silverlight scored 304. Obviously, the results will vary depending on what you find important. Which is why we asked an analyst from one of those large IT research & advisory companies to give us some feedback on this. The analyst agreed entirely with our findings and our data, and confirmed that his company is recommending moving towards HTML5 to all of their customers. He even went as far as to say that Silverlight is hard to recommend, unless you're not targeting any mobile users and the applications are internal-only and you've already invested in the technology. I can't provide a link for any of this yet, but a paper about this will be published soon so i'll either link to it when it's out (if it's publicly available) or at least reference it.

Таким образом, мы имеем 3 категории, в которых Silverlight оценивается лучше, чем ASP.NET MVC 3 + JQuery, но этого недостаточно для того чтобы сократить отрыв. Основываясь на весе, который мы присвоили каждому критерию, максимально возможная оценка это 732 балла. ASP.NET MVC3 и jQuery набрали 568 балла. Silverlight набрал 304 балла. Очевидно, что результаты будут отличаться в зависимости от того, что вы считаете важным. Именно по этому, мы проконсультировались с аналитиком из одной крупной компании, специализирующейся на исследованиях и консалтинге в сфере IT технологий. Аналитик полностью согласился с нашими выводами и данными, и подтвердил, что его компания рекомендует переход к HTML5 для всех своих клиентов. Он даже зашел дальше, и сказал, что Silverlight трудно рекомендовать, разве что, в случае, если ваши приложения не нацелены на поддержку мобильных платформ и являются сугубо внутренними и вы уже вложили деньги в эту технологию. Пока что, я не могу предоставить ссылку на это мнение, но документ об этом будет готов в ближайшем будущем, и я лучше дам ссылку, когда он выйдет (если документ будет публичным) или, по крайней мере, сошлюсь на него.

I encourage anyone who is faced with the same decision to use the spreadsheet and modify it to your needs (adding more criteria, changing weights and/or scores, whatever) to see which one is the best fit for your situation. You can download the spreadsheet here.

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

Резервная ссылка MS Excel 2007 (html_vs_silverlight.xlsx)
Резервная ссылка MS Excel 2003 (html_vs_silverlight_xl2003.xls)


Перевод текста: Дмитрий Жарий


Davy BrionАвтор текста: Davy Brion – .NET разработчик, блоггер, владелец бизнеса.
Оригинал текста: Why We’re Going With HTML(5) Instead Of Silverlight