Этой тарахтелкой можно пугать беременных кошек, но какой прок от неё в бою? — генерал Китченер о первом танке, 1915.

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

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

Я сделал отступление, чтобы написать для чего это нужно. Потом развил отступление. А потом взял и написал пост, почему я считаю, зачем нужны и полезны гигабайты и много-много ядер.

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

Во время dot com бума мы с друзьями основали стартап, где я был техническим директором. Мы разработали систему управления знаниями. Это была комбинация блогов, wiki, системы управления документами, социальных закладок. Мы начали в 1999, что было несколько рановато для wiki и блогов (Movable Type вышли на рынок в 2001). Социальные закладки, по сути, были точно такими же, как станет впоследствии Delicious. Помимо этих новых и замечательных идей (по крайней мере для 1999 года) у нас было три отличных особенности:

• Всему можно было присвоить метки (tags): навыкам, людям, ссылкам, документам, постам в блогах, страничкам в wiki. Что-то, что теперь называется фолксономия. Метки могли соотноситься с другими метками и формировать онтологии. Метки могли ссылаться на другие документы, посты, людей.
• Всему можно было поставить свою оценку от 1 до 5.
• У нас был умный нечёткий поиск, основанный на метках и оценках. Например, при поиске «люди со знанием Oracle» в выдачу также попадали специалисты по SQL Server'у — например, чтобы укомплектовать команду, если не было свободных гуру Oracle.

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

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

Дано: заказчик за рубежом, желающий работать с Вами и платить вам евро или доллары.
Найти: оптимальный способ организовать работу с ним, чтобы платить налоги и спать спокойно.

Сразу скажу, что получение денег на пластиковую карту без уплаты налогов может вылиться в серьезные проблемы (про ответственность написано в конце топика). Объяснения, что деньги «от бабушки внучку на мороженное» при суммах больше 10К$ в год уже не прокатывают, особенно если в реквизитах «бабушки» будет стоять что-то вроде «GMBH Star Development» Вероятность того, что возьмут за задницу достаточно высокая и поэтому лучше не рисковать и делать все по Закону, тем более, что ничего сложного в этом нет

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

Я затвитил эту статью о 5 причинах проводить обзоры кода на CIO.com на прошлой неделе и понял, что на самом деле причин гораздо больше, чем те пять, о которых там написано. Так что к концу дня у меня их было уже больше 20. Это коллекция тех твитов с некоторыми подробностями, описанными здесь.

Причина №1. Достаточно быстрая ответная реакция, чтобы подстегнуть разработчика.
Так как обзор кода производится после кодирования и перед интеграционными и системными тестами, разработчикам не надо ждать столько же, сколько и ответа от отдела по качеству кода (QA). Обеспечив конкретный, своевременный ответ, разработчики могут подстраивать свои навыки кодирования для избежания общих ошибок.

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

• Один не мылся и вонял так, что в комнату не зайти. Я угрожал поставить вытяжку и вычесть из зарплаты; это помогало на один душ, не больше.
• Другой пил запоем и врал, что отравился брюшками семги.
• И все, почти все затягивали сроки.

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

Поиск кандидатов

Очередного программиста я нашел так: отобрал несколько откликов на HeadHunter.ru и попросил их посмотреть, чем они займутся. Вот что я написал:

Хороший код

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

Основное правило

Я считаю, что читаемым является код, в который можно не вчитываться.
То есть, пары-тройки строк дожно быть достаточно, чтобы сказать, что делает класс или метод. Ещё пары-тройки — чтобы примерно сказать, как он это делает.

Прочие замечания

Я заметил, что есть ещё несколько довольно общих правил, которые делают код симпатичнее.

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

Наиболее важный урок, который мы получили работая с App Store — большинство неудачливых разработчиков App Store все еще не поняли: если по названию и короткому описанию мама сразу понимает что это, программа будет продаваться более чем в 30 экземпляров в день. Если из названия и описания мама не понимает о чем идет речь, программа будет продаваться менее 5 экземпляров в день. К сожалению, другие разработчики App Store не имеют доступа к моей маме или ее вкусным рогаликам, поэтому мы будем и впредь сохранять это стратегическое преимущество.

Основная причина успеха программы: Убедитесь, чтобы описание вашей программы было предельно понятно. Если это не так, то упростите.

Должен предупредить, что это ещё одна статья, не содержащая никаких откровений. Для тех супер-гиков, которые назубок знают весь perldoc, она будет абсолютно бесполезной, так что, уважаемые супер-гики, можете проходить мимо и не информировать, что всё это есть в доках. Я и так это знаю. :-) Моя статья для всех остальных, для тех, кто весь perldoc целиком либо не осилил, либо осилил, но не понял, либо понял, но не запомнил.

Я думаю, многие знают о так называемом операторе диапазона, записывающемся как .. (две точки), с помощью которого можно быстро создавать массивы из набора последовательных элементов. Например, следующий код создаёт массив из 35 чисел: 3, 4, 5, …, 37:

my @arr = 3 .. 37;

Помимо чисел можно использовать строки: в этом случае для генерации элементов массива будет выполняться так называемый магический инкремент (например, можно задать диапазон букв: 'a' .. 'z').

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

-О чём вы, Морфеус?

Количество фреймворков в мире растёт с пугающей скоростью. Тысячи их уже на данный момент. Благо, лучших из низ — не так много. Весь мир Web разработчиков просто подразделился на несколько групп, которые отадют предпочтение тому или иному фреймворку. Я не люблю тёрок и холиваров, так что бог с ним с тем, что лучше. Я лишь хочу поговорить с разработчиками ASP.NET о Ruby on Rails.

Зачем?

Расскажу свою историю. На ASP.NET я пишу с 2004 года. Знаю множество закоулков данной системы и знаю, что она сама по себе восхитительна. Я пережил 3 больших проекта на .NET и написал с 10 сайтов, которые сейчас продолжают стабильно работать. Если говорить о фрейворкнутости, то .NET меня удовлетворял всем. В самых больших проектах я находил решения самых сложных задач. И вот, через 6 лет мне просто захотелось посмотреть, а что же есть другого на рынке? Естественно, первым делом я наткнулся на RoR.

У книги Карла Фогеля «Producing open source software» замечательная обложка (см. выше). На ней показано множество маленьких стрелок разного размера, указывающих направо, и бо́льшая стрелка жёлтого цвета, на мой взгляд показывающая итоговый эффект. Она как бы говорит нам: если все лошади будут тащить в одном направлении, можно будет передвинуть на другое место целый дом.

Я понимаю ее именно так, потому что она напоминает мне кучу разных рисунков, которые делались на занятиях физики. Если шар ударяется о другой вот так и под вот таким углом, куда упадёт ботинок? Что-то такое.

Это красивая картинка, и именно так я представлял себе опенсорс, пока не стал в нём участвовать. Все люди тащат проект в одном направлении, чтобы сделать энциклопедию, или операционную систему. Но, скажу я вам, это совсем не так, пока проект не вырос

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

Amy Editor

Созданый в 2007 Петром Кронторадом (Petr Krontorad), Amy Editor продвинутый редактор с интерфейсом в стиле Mac. Amy Editor имеет в наличие кучу полезных опций, такие как нумерация строк, подсветка синтаксиса, сниппеты для более чем 20 языков, совместное использование и прочее.

» http://www.amyeditor.com

Промедление — это то, чем мы занимаемся каждый день:

1. «Мне завтра нужно сдать курсовую, которую я еще не начинал, но, чтобы сконцентрироваться, мне сейчас надо отдохнуть и попить кофе»
2. «Я хочу начать бегать по утрам, но сначала мне нужно сдать сессию и найти хорошую работу, которая обеспечит мне стабильность и уверенность»
3. «Перед тем, как начать работать, мне нужно ответить на 11 писем и поговорить с друзьями по аське о летней поездке в Испанию, чтобы не отвлекаться в течение дня»

Введение

«Наибольшей выгода будет тогда, когда каждый в команде будет думать не только о своем успехе, а о своем успехе и об успехе команды в целом»
Х/ф «Игры разума»

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

Сам я работаю ведущим программистом, руковожу группой программистов.

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

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

А что за четыре прошедшие дня никто не написал про развитие темы habrahabr.ru/blogs/development/80236? =)

Ребятки из Wolfire за это время написали реакцию на негативные отзывы (почитать оригинал можно по ссылке blog.wolfire.com/2010/01/DirectX-vs-OpenGL-revisited)

Основные идеи такие:

Доброго времени суток.

В этой статье я хочу продолжить рассказ о «прагматическом» Agile процессе разработки ПО. На суд Читателя предлагается иная перспектива обзора этого процесса — с точки зрения создания и эволюции артефактов (Artifact Flow) в ходе развития проекта. А также мы рассмотрим практический подход для работы с артефактом «Коллекция Требований» с использованием Google Wave и Google Docs.

Студентов MBA на западе учат древней индейской мудрости — если Вы замечаете что лошадь, на которой Вы скачете сидите, мертва, то лучше всего с неё слезть. Применимо к бизнесу и стартапам это означает, что если продукт помер, его часто лучше списать в утиль и идти дальше, чем вкладывать деньги в реанимацию или особенно бездействие. Замечу, что даже сидя на мёртвой лошади менеджмент может быть уверен, что скачет галопом в светлое будущее. Многие будущие CEO эту мудрость на вооружение берут более дословно — мол не зазорно уйти с тонущего корабля одним из первых, существуют и другие выводы, результирующие из недо-, пере- и иначе-понимания этой мудрости.

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

Что мы делаем когда закрадывается смутное предположение, что компания скачет на мёртвой лошади:

[ Индикаторы класса «Возможны ложные срабатывания» ]
— Мы достаём более хлёсткий и мощный кнут для мёртвой лошади (а нередко и на конюхов розг хватает)
— Ждём, ничего не делаем, ведь мы всегда точно так ездили на мёртвых лошадях и раньше проблем не было
— Меняем наездника. Когда мёртвая лошадь не скачет виноват обычно он
— Облагораживаем стойло, достаём конюхам пряников
— Едем за бугор, там с незапамятных времён водились наездники на мёртвых лошадях, перенимаем их опыт
— В добровольно-принудительном порядке предлагаем курсы верховой езды сотрудникам отдела
— Создаём группу и анализируем мёртвую лошадь, время смерти и меру окоченения
— Признаём мёртвую лошадь неверно аттестованной, она живее всех живых

Более веские приметы под катом

Существует много способов по верстке колоночных макетов. Уже не один нос разбит в течении холиваров, разожженных по поводу использования тех или иных методов. Казалось бы, что все должно быть предельно ясно и понятно, но все-равно возникает много трудностей. Я хочу и свою лепту вложить во всеобщее благое дело, и потому потратил относительно немного времени на эксперименты, которые привели меня к созданию еще одного метода, в котором есть следующие плюсы и минусы:

Плюсы

• Есть прижимающийся к полу футер
• Колонки меню растягиваются по 100% высоте
• Колонок может быть сколько душе угодно
• Колонки могут быть как лево- так и правосторонними, а также совмещенными, например 2 справа и 1 слева
• Ширина как резиновая, так и фиксированная
• Критический минимум хаков
• Не используется Javascript
• Не используются бекграундовые изображения для создания эффекта колонки
• Никаких таблиц
• Одинаковый результат в ie5.5, ie6, ie7, ie8, ff3.5, o10, chrome4 (Если у вас не работает в каком-то браузере — отпишитесь, пожалуйста, в комментах. Исправим и приведем к универсальному виду)

Минусы

• Есть несколько «лишних» блоков. (Я бы и сам рад от них избавиться)
• Есть несколько абсолютно-позиционируемых блоков

Это статья о работе фрилансеров. Сам я много раз выступал как в роли заказчика, так и в роли исполнителя работ; наш аккаунт на free-lance.ru занимает 5 место в рубрике "сайты под ключ", хотя ему всего 9 месяцев (пока писал, сместился на 6-ое место).
Хочу поделиться с вами некоторыми соображениями об успешном фрилансе.

1. Правильное взаимодействие с заказчиком – половина успеха.

Грамотное общение с заказчиком – это половина успеха проекта. Помните, недостаточно быть хорошим программистом или дизайнером, чтобы быть успешным фрилансером. Вы еще и менеджер. Много зависит от того, как вы сумеете продать свои услуги, как будете общаться с заказчиком в процессе выполнения работы.
Заказчика в основном интересуют три вещи: адекватность исполнителя, его опыт (портфолио) и цена. Чуть менее – сроки работ.
Показать то, что вы вполне адекватный человек, с которым можно работать – это самое легкое из этого списка. О некоторых простых вещах при общении многие фрилансеры забывают. Не выставляйте заказчика дураком, даже если он действительно совершенно не разбирается в вопросе. Не дайте почувствовать ему себя ламером. Объясните ему суть вопроса без использования узкопрофессиональных терминов, посоветуйте лучший вариант реализации. При общении не используйте сленг, обращайтесь к заказчику на «вы», пишите без грамматических ошибок. Особенно актуально, когда вы говорите с потенциальным клиентом — вы ничего о нем не знаете. Может он старше вас в два раза и обращение «привет» его коробит.

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

Каждый заказчик хочет заплатить поменьше, получить побольше. Это нормальное желание каждого клиента и покупателя. Но все имеет свою стоимость. И не каждый это понимает, пытаясь сильно сбить цену. Держите свою планку. Можно сделать небольшую скидку, но если заказчик хочет сбросить цену вдвое – значит, это просто не ваш клиент. Цените свой труд. У заказчика может быть масса надуманных причин, с помощью которых он станет просить изменить цену. Самые популярные:
Сейчас я у меня только эти деньги на проект, но в будущем у меня будет много денежных заказов для вас. Когда-нибудь, может быть. Это не повод снижать цену.
Давайте вы поработаете за % от прибыли будущего проекта. А заказчик тогда вообще зачем нужен?
Мой начальник выделил определенный бюджет, я бы рад заплатить больше, но не могу. Практически любой бюджет можно пересмотреть. Нет? Но тогда это проблема заказчика.
А у Васи Пупкина дешевле. Что же вы тогда не заказываете у него?