Вступление

Я, как руководитель проектов, всё больше и больше замечаю, что эффективность работы команды (и каждого программиста в частности) – это ключевой фактор, определяющий успех проекта. При эффективной работе даже самые тяжёлые проекты со сжатыми сроками удаётся завершить успешно, а неэффективная способна «завалить» простейшие проекты с минимумом рисков. Поэтому, я хотел бы поделиться своими мыслями об одном из ключевых понятий – понятии «работы потоком».

Добрый день!

Как представитель проекта Лекториум рад сообщить — мы опубликовали весь архив Computer Science клуба.
Кроме того, почти год назад мы организовали запись всех лекций на хорошие камеры и микрофоны.
А в этом году планируем подключить вебинары.


Большинство лекций читается на русском языке. Все записи снабжены презентациями и описаниями.

UPD. Кратко. Старые лекции в плохом качестве, а новые с 2010 года с хорошим звуком и в 720p.
UPD 2 Расширили канал, видео грузится теперь без проблем.

Под катом перечень курсов и несколько вопросов касательно вебинаров.

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

По истечению этого срока проекты были сданы «оценочной комиссии», которой являлись наши общие друзья. И… Мой проект не выиграл. А самым обидным на тот момент казалось то, что, по условиям спора, я должен был выделить ещё одну неделю рабочего времени, чтобы помочь своей оппонентке в развитии её игры. Но спор есть спор!

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

Замечательный сайт www.sorting-algorithms.com позволяет увидеть, как сортируются данные разными алгоритмами. Вы сможете посмотреть анимацию в зависимости от алгоритма, исходных данных.



Все это бегает и сортируется прямо на ваших глазах!

Работает на Google App Engine, видимо, поэтому и лежит от посетителей с «Хабра».

Рано или поздно все сталкиваются с проблемами связанными с языковым и культурным разнообразием при написании программ. Я был сильно удивлен узнав, что часть моих знакомых, пишущих на C++, решают эти проблемы своими велосипедами. Для тех, кто еще не знает что такое std::locale я хотел бы кратко на примере показать как c ним работать и что бывает, если о нем забыть…

Любой программист хоть раз заглядывавший в отладчик знаком с понятием точки останова (aka бряк, breakpoint). Казалось бы нет ничего проще, чем поставить точку останова пара кликов мышкой в графическом интерфейсе или команда в консоли отладчика, но не всегда жизнь системного программиста столь проста и иногда возникает необходимость выставлять точки останова автоматически — изнутри самой программы.

Как разработчик, вы сидите на золотой жиле. Вы осознаете это?

Нет, серьезно, на @#$% золотой жиле! Никогда в истории не существовало возможностей так легко создать что-то с нуля, с маленьким или отсутствующим начальным капиталом и маркетинговой моделью, ограниченной только вашим воображением.

Подумайте о крупнейших сайтах, которые вы постоянно посещаете: Facebook, Twitter, Flickr, Foursquare, или даже Google — все они были созданы разработчиками, у которых была лишь идея. Было ли это легко? Черт, нет. Но это могло быть сделано только в наше время. Так, черт побери, почему вы просиживаете день за днем, работая на кого-то?

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

Но, что делать, если только начинаешь? Прежде чем станут обращаться клиенты, могут быть проблемы с тем, что делать целый день. Это идеальное время, чтобы дать о себе знать.

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

Будучи программистом я многое узнал о том, как создаётся программное обеспечение. Вот несколько фактов, которые могут вас удивить.

Предисловие

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

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

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

1. Будьте самостоятельными

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

Забавный «конструктор» речей В.В Путина создал журнал Esquire.



В данном веб-приложении можно составить текст из заранее выбранных слов и затем «откомпилировав» его прослушать речь премьер-министра.

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

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

Прямая ссылка после обрезания кода выглядит вот так: http://video.esquire.ru/plays/mediaplayer/player.swf?bufferlength=3&file=http://video.esquire.ru/speaker/upload/bfdd896c3df2f0b6ab99187e22349748.flv


Забавляйтесь.

В продолжение темы о создании собственного USB-гаджета.
Создание простого устройства.

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

Сейчас, пожалуй, только староверы в глубокой тайге не знают, что такое фриланс. Причем те из них, кто еще не отдал добычу еды на аутсорсинг. И вместе с тем, как набирает обороты движение свободных разработчиков, рождается множество забавных, а, порою, опасных религий, с этим связанных. Про одну из них мне и хотелось бы поведать. Мотиватором для этого послужила данная статья на Хабре — habrahabr.ru/blogs/pm/95548.
NB: Статья, разумеется, шутливая и позже была перенесена в ХабраЮмор, но нас ведь не проведешь и мы прекрасно понимаем, что юмор используется для того, чтобы на рынок умов могло проникнуть то, что не пустят через парадный вход. Как говориться, политический анекдот — это тоже шутка. В общем обратите внимание, что рассматривается не упомянутая статья, а религия, частным порождением которой эта статья и является..

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

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

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



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

Но обо всем по порядку.

Понимание роли мозга

Нет невежества страшнее, чем невежество по отношению к самому себе.

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

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

Специально для Хабра (для людей с техническим складом ума) я подготовил краткую версию статьи о мозге, в которой описано, что полезно для мозга, а что нет. Добро пожаловать под кат.

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

Память наше всё!

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

В форумах люди часто упоминают, что 64-битные версии программ поглощают больший объем памяти и стека. При этом обычно ссылаются на то, что размеры данных стали в 2 раза больше. Однако это необоснованное утверждение, так как размер большинства типов (char, short, int, float) в языке Си/Си++ остался прежним на 64-битных системах. Конечно, например, увеличился размер указателей, но ведь не все данные в программе состоят из указателей. Причины роста потребляемой памяти и стека более сложны. Я решил подробнее исследовать данный вопрос.

В данной заметке я поговорю о стеке, а в будущем планирую обсудить выделение памяти и размер двоичного кода. И еще хочу сразу заметить, что статья посвящена языку Си/Си++ и среде разработки Visual Studio.

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

Стадия первая. Рождение

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

Знакомтесь, это первая стадия. Она, в отличие от следущих, особенно характерна именно для олимпиадников. Пациент думает о том, как написать быстрый код. Он одержим быстрым кодом. К сожалению, наличие быстрого кода не всегда делает быстрым программный продукт в целом.

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

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