Чувак плачется, что индусы убивают рынок фриланса в вебе, соглашаясь делать работу, которая стоит 100 баксов, за 10.

По-моему, чувак не прав. Причина этих 10-20 долларовых проектов в том, что в вебе всё больше и больше готовых коробочных решений и всяческих сервисов. Соответственно, заказчику стало проще подобрать нужное решение из готовых (или платных, или бесплатных) и заплатить копейки (как правило индусу) за допиливание и прикрутку.

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

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

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

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

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

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

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

В частности, Windows.

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

Самый простой способ разобраться с ошибкой — вбить её текст в google и почитать, что написали пользователи, сталкивавшиеся с этой ошибкой раньше.

Этот способ позволяет разобраться с приблизительно 90% всех ошибок (не только пользовательских, но и программистских — дебажить с гуглом гораздо веселее, чем без него, хоть это и расслабляет, отучая мозги думать).

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

А у локализованного софта пользователей гораздо меньше, чем у нелокализованной версии. Соответственно, поиск по локализованному тексту ошибки даёт меньше результатов, чем поиск по её оригинальному тексту. Проблема в том, что не всегда удаётся точно перевести сообщение об ошибке на язык оригинала (отдельный привет надо передать локализаторам).

А винда у меня (к сожалению) русская, т.к. покупалась вместе с ноутом.

Столкнулся с необходимостью выбрать инструментарий для ведения документации по проекту. Получается, что если в команде нет отдельного (специально выделенного) человека, который ведёт всю документацию, то инструментарий должен поддерживать коллективную разработку документации. Как минимум — уметь делать versioning, diff и rollback.

Два ключевых слова — “документация” и “коллективная” приводят к очевидному решению — wiki. Решение настолько очевидно, что можно найти testimonials людей, использовавших wiki для документирования разработки software:

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

Очевидно, что сама по себе wiki не справляется с задачей: нужны костыли для привязки к багтрекеру, svn-у, php-docу (или его аналогу). Ещё более очевидно, нужен “архивариус” — человек, который будет поддерживать порядок в документации, реструктуризировать дерево. Похоже, что при определённой активности и дисциплинированности пользователей (т.е. разработчиков, тестеров и менеджеров) роль архивариуса удастся свести именно к поддержанию порядка.

При этом меня не покидает ощущение того, что wiki-разметка — это недо-html. А в компании, занимающейся web-разработками, основы html знает даже корпоративная морская свинка™. Спрашивается: зачем людям, знающим html, насиловать себя и писать вместо <i>привычных тегов</i> //какие-то недотеги//, которыми они нигде, кроме этой самой wiki не пользуются, в отличие от нативных html тегов?

Среди всех претензий к wiki её недо-htmlьность — самая мелкая.

А теперь самое время вернуться к тому, с чего всё это начиналось: нам нужен инструмент, позволяющий вести коллективную разработку документации. Как минимум — уметь делать versioning, diff и rollback.

А ведь у нас уже есть такой инструмент: это Control Version System, система контроля версий. Стандартная CVS позволяет делать versioning, diff и rollback для текстовых файлов.

Итак, самое дешёвое решение — вести документацию в текстовых файлах, контроль версий возложит на CVS, которая уже есть в проекте. Грубо говоря, если в CVS есть директория Source с исходниками проекта, то рядом надо сделать папку Docs с его документацией в текстовых файлах.

Беда в том, что документация — это не текст. Даже если обойтись без таблиц, иллюстраций и форматирования, документация — это как минимум гипертекст. Значит, надо вести документацию в формате html, и хранить её в CVS, ибо html файл — это текстовый файл. Редактировать документацию сможет каждый, как и в случае с wiki — для этого подойдёт любой html-редактор, даже блокнот.

Versioning для html файлов будет по-прежнему обеспечивать CVS. Единственное, что надо согласовать — это правила форматирования документации в html. Типа: для жирного используем <b>, а не <strong>; абзацы делаем с помощью <p>; ссылки ставим только относительные. Точно такие же соглашения существуют и в отношении кода: как ставим {скобки}, что используем для табуляции — пробелы или табы.

Соорудить надстройку над этой документацией в формате html не очень сложно: нужны индексы (предметные указатели), нужен поиск, нужны пути, нужен список последних правок, нужны специальные теги для багов и вопросов. В общем, костыли кажутся не более сложными, чем костыли для wiki.

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

В понедельник Google выпустил Protocol Buffers — формат хранения данных, позициниоруемый гуглом как частичная замена XML.

Вот как выглядит пример XML:

  <person>
    <name>Йа Креведко</name>
    <email>ja@kreved.co</email>
  </person>

А вот так выглядит та же информация, записанная с помощью Protocol Buffers (в текстовом формате):

  person {
    name = "Йа Креведко"
    email = "ja@kreved.co"
  }

Кроме текстового формата, Protocol Buffers может быть бинарным — т.е. Human Readability, как в случае с XML, не гарантирована.

Для любого файла в формате Protocol Buffers нужен файл формата .proto, в котором описывается структура данных:

message Person {
  required string name = 1;
  required int32 id = 2;
  optional string email = 3;

  enum PhoneType {
    MOBILE = 0;
    HOME = 1;
    WORK = 2;
  }

Google и сам пользуется этим форматом во многих своих проектах, и другим рекомендует его вместо XML для сериалайзинга структурированных данных, ибо Protocol Buffers по сравнению с XML:

• проще
• в 3-10 раз меньше
• в 20-100 раз быстрее
• менее неопределённые
• порождают классы для доступа к данным, которые легче использовать программно

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

Программа Programeter на основе анализа исходников проекта в репозитории позволяет оценить/измерить такие характеристики работы каждого программиста:

• уровень знакомства программиста со всей базой исходников;
• количество нового, привнесённого этим программистом кода в репозиторий;
• уровень “выживаемости” кода программиста;
• размер общего вклада программиста в репозиторий;
• уровень активности в течение одного месяца;
• ориентированность на сотрудничество с другими программистами;
• среднюю сложность написанного кода;
• соотношение объёма написанных комментариев к объёму написанного кода.

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

Почему менеджмент, принимающий решения на основе таких показателей маразматичен?

Потому что все эти циферки накручиваются, с разной степенью лёгкости.

Например, повысить уровень “сотрудничества с другими программистами” можно так: договориться группой в курилке о том, что как только у кого-то возникает потребность в новой “библиотечной” функции, он сообщает об этом коллегам и кто-то (кому нужно поднять уровень сильнее всего) создаёт эту функцию.

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

А накручивать обязательно будут, если накрутка приносит какую-то выгоду (повышение или непонижение з/п, например). Вот выдержки из реальной истории о том, как в одной конторе начали оценивать работу программистов по количеству коммитов в неделю (в переводе Сергея Можайского):

“С помощью его скрипта он мог сделать из одного коммита 20-30. Он вполне мог ожидать повышения, поскольку его продуктивность [по меркам системы] возросла более чем на 600%.

Несмотря на то что это длится уже два месяца, удивительно, что начальник и не подозревает о том, что большинство коммитов - однострочные изменения, или что исправление опечатки в слове “guarantee” в форме заказа потребовало более дюжины коммитов.”

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

В общем, если в вашем проекте решения о уровне полезности программистов принимаются не на основе мнения ведущего программиста, а на основе таких вот “показателей надоев”, то дело плохо.

Задача: создать в JavaScript массив из одного элемента, равного значению переменной x.

Очевидное решение var a = new Array(x); — неправильно.

Если переменная x имеет тип number и является целым числом (например, x=5), то вместо массива с одним элементом, равным 5, мы получим пустой массив из пяти элементов. А если x является дробным числом (например, x = 5.2), то мы вообще получим ошибку invalid array length. Если x — строка, то решение сработает.

Причина такого поведения браузеров в том, что при создании массива через Array(x) интерпретатор ведёт себя по-разному в зависимости от типа переменной x. Если он получает тип number, то он трактует этот параметр как длину создаваемого массива, а не как значение нулевого элемента.

Правильный ответ: var a = [x];

Задача: средствами PHP отправить письмо через smtp.gmail.com. Не просто с указанием адреса @gmail.com в поле From:, а именно через гугловский сервер.

Зачем это нужно? Во-первых, на многих хостингах существуют всяческие ограничения по использованию почты. Во-вторых, такое письмо должно выглядеть “белее” письма, отправленного локальным smtp: меньше шансов, что оно попадёт в junk folder.

Основная проблема, которая возникает при отправке письма через smtp.gmail.com и не возникает при отправке писем по smtp через другие, более обычные сервера, состоит в необходимости использования TLS соединения на 465 порт.

Отправить письмо из PHP напрямую через SMTP сервер (а не через mail() или sendmail) можно давно с помощью LGPL библиотеки PHPMailer.

Оказывается, начиная со второй версии, разработчики библиотеки добавили поддержку отправки почты по SMTP по безопасному соединению. Вот code snippet, формирующий правильный вызов метода отправки письма при использовании гугловского smtp:

     $mail->Mailer = “smtp”;  
     $mail->SMTPAuth = true;  
     $mail->SMTPSecure = “tls”;
     $mail->Host = “smtp.domain.com”;  
     $mail->Port = “465″;  
     $mail->Username = “email.address@gmail.com”;  
     $mail->Password = “1W0N’T_t3ll-U”;  

Разработчики библиотеки не волшебники: для отправки писем по безопасному SMTP-соединению необходим PHP с поддержкой OpenSSL.

Все holywars, посвященные тому, какой язык программирования лучше, — совершенно бессмысленны.

Один язык программирования может быть удобней другого языка программирования для решения какого-то класса задач.

Оценивать язык программирования абстрактно (и сравнивать его с другим) бесполезно.

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

Т.е. для сравнения языков их сначала надо спроецировать на какую-то задачу.

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

Потому что WTF — это производная не от языка, а от программиста.

Профессионал решит задачу на том, на чём скажут. Поплюётся, но сделает VBScript для автоматизации в Excelе. Скривится, но допишет нужный функционал к PHP-шному скрипту.

А вот от кривизны рук никакой язык не избавит. Немного выровнит, но не избавит.

Если бы избавлял, то сидели бы все и писали на C.

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

<script src=”http://my.edge.cached.startup.com/dojo-1.0.0.js” shared=”http://o.aolcdn.com/dojo/1.0.0/dojo/dojo.xd.js”></script>

Если в кеше браузере уже есть скрипт с uri, указанном в shared, то его можно будет не грузить.

Это — потенциальное дополнение к тегу script, которое может появиться в HTML5. Об этом рассказывает создатель JavaScript Brendan Eich (via Alex Moskalyuk).

Основным способом ввода информации в CMS через веб являются элементы управления типа <textarea>.

Для удобства пользователей и увеличения скорости ввода информации эти контролы часто заменяют на WYSIWYG-редакторы (What You See Is What You Get).

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

Разработчикам же для внедрения WYSIWYG-редактора требуется установить на сервер сам редактор, настроить его и вставить в шаблон пару javascript строк для замены плоской <textarea> на неплоское поле на клиенте.

При этом разработчики часто совершают ошибку: внедрив WYSIWYG в свою CMS, они не дают пользователю возможности не использовать этот WYSIWYG.

Речь не идёт о тех клиентах, которые не поддерживаются WYSIWYGом — в них контрол выглядит старой плоской <textarea>. А вот если у пользователя нормальный клиент, но при этом, например, интернет по GPRSу, то бедный этот пользователь: чтобы добавить контент ему понадобится достаточно много времени и денег (WYSIWYG подгружает достаточно много дополнительных файлов: javascript, css, images).

WYSIWYG надо внедрять так, чтобы у пользователя всегда была возможность не пользоваться им. Переключение между WYSIWYGом и plain <textarea> должно происходить без перегрузки страницы.

При этом plain <textarea> не должна быть действительно plain: к ней необходимо прикрутить quicktags для гиков.

Из всех WYSIWYGов наиболее удобным является TinyMCE.