Введение

В этом топике я хочу представить вам, дорогие читатели, пересказ вебинара от человека, чьё имя не нуждается в представлении. Для того, чтобы изложить часовой вебинар в виде небольшого топика, мне пришлось значительно ужать комментарии автора, поэтому я сознательно не помечаю топик как «перевод». В этот раз Стив МакКоннелл решил поделиться с нами своим опытом в виде коротких тезисов, в которых он отражает самые страшные ошибки при оценке трудоёмкости разработки программного обеспечения. В 1998 году читатели журнала Software Development назвали Стива одним из самых влиятельных людей в индустрии разработки программного обеспечения на равне с Биллом Гейтсом и Линусом Торвальдсом. Стив — автор книги «Software Estimation. Demystifying The Black Art» — одной из самых популярных книг в области оценки трудоёмкости разработки ПО. Надо признаться, что вебинар был проведён относительно давно (июнь 2009 года), но информация, представленная там, совсем не устарела. Сам топик будет построен следующим образом. Заголовки будут достаточно точно переведены из презентации, которую показывал Стив, а в остальном я постараюсь отразить только основные мысли, чтобы не перегружать топик. Если кто-то посчитает, что ту или иную мысль я излагаю неправильно — милости прошу в комментарии, можно будет меня поправить.

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

1. Введение

В данной статье я хотел бы рассказать об этих трёх буквах, постоянно находящихся на слуху, но для многих являющихся тайной за семью печатями, а так же привести ряд ресурсов, с которыми неплохо было бы познакомиться при желании продолжить развитие в проектировании на основе предметной области (DDD: Domain Driven Design).

История одного проекта.

Делая проекты и работая, сидя за компьютером, по 12-15 часов в сутки (часто и дольше), я начал замечать как мои глаза начали слезиться и краснеть, шейные позвонки просто ныли (небольшой стресс и они просто не давали спокойно жить), кисти рук, поясница и ноги немели. Вечером, поужинав, засыпал, но ночью просыпался и опять работать. Вырос живот, обвисли мышцы, стал раздражителен.
Хотя все мы знаем о пользе гимнастики. Читали, сохраняли много упражнений себе в «Избранное» (у самого куча подобного в избранном и на дисках). Может пару раз, потом забывали или лень, или не хватает времени, глядя в зеркало и обещая себе «В понедельник начинаю новую жизнь!». Это не очередная статья, которая рассказывает о том, чем нам грозит сидячий образ жизни и какую пользу приносит гимнастика – вы наверняка знаете об этом предостаточно.

Позвольте рассказать свою историю, от понимания проблемы, до реализации решения в виде сервиса…

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

Прошлым летом совершенно неожиданно для себя я приобрел смартфон Nexus One. Своей покупкой был страшно доволен и подолгу ковырялся в его софтовой начинке, восхищаясь продуманностью системы. Поскольку я уже давно являюсь разработчиком игр, захотелось смастерить что-то свое и для этого устройства. После достаточно плотного изучения платформы, чтения специальной литературы, появились и первые ласточки в виде различных украшательств экрана. Надо заметить, что несмотря на то, что я с java никогда серьезно не работал, язык показался легко осваиваемым и интуитивно понятным. Очень сильно помогла и документация от Гугла. Все это в совокупности вселяло надежды на успешную разработку первого серьезного проекта, дизайн которого уже начал складываться с первых шагов изучения Android. Энтузиазма добавил и тот факт, что после пробного выкладывания приложения с живыми обоями на маркет за первые сутки его скачало почти тысяча пользователей. В голове завертелись мысли о коммерческих проектах и «легкой наживе».

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

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

Спрос на Android-разработчиков весьма велик сейчас. Я решил подготовить список того, что нужно знать каждому разработчику под эту платформу. Это не только то, что вас могут спросить на собседовании, а весь спектр знаний, который скорее всего пригодится в работе. Бонусом идет пара интерсных вопросов про платформу.

Сделано под вдохновением этого топика.
Обычный JavaScript, к которому все привыкли, не даёт средств работы ни с файловой системой, ни с двоичными данными, поэтому все описанное ниже будет про node.js.

В век всеобщей компьютеризации образование становится все доступнее. Онлайн можно посмотреть лекции именитых профессоров, поучаствовать в вебинарах, получить образование в Оксфорде или Кембридже. В этом топике я хотел бы коснуться образовательных трекеров, предоставляющих на бесплатной основе подчас неоценимые материалы. BitMe.org, BitSpyder.net, LearnBits.me, Elbitz.net уже подробно рассмотрены. Итак, новые участники обзора:

Все чаще можно услышать про универсальных трекеров-монстров типа ThePirateBay.org, torrents.ru или упоминания трекеров музыкальной либо игровой тематики. Но помимо них давно существуют торрент-трекеры обучающей направленности, о которых мало что известно рядовому пользователю. В основном, это закрытые сообщества образованных людей с регистрацией по приглашениям, которые обмениваются обучающими материалами, будь-то электронные книги, обучающее видео, CBT (computer based trainings), аудио-книги, презентации с конференций или софт для обучения. Преобладающая часть материалов связана с ИТ-технологиями и поэтому будет особенно полезна ИТ-специалистам, от студента, изучающего Linux, PHP или C# и до гуру, который готовится к сдаче CCIE. Также присутствует материал, посвященный изучению иностранных языков, психологии, саморазвитию, соблазнению, развитию бизнес-навыков. Если ты подумываешь сдать на CCNA, MCSE, RHCE, CISSP, Network+, PMP, IELTS/TOEFL и так далее — то здесь можно найти все необходимое и даже больше. Под катом находится обзор англоязычных ресурсов обучающей направленности.

Вторая часть статьи.
Большинство современных вычислительных машин, будь то суперкомпьютер Fujitsu K, обычная персоналка или даже калькулятор, объединяет общий принцип работы, а именно модель вычислений, основанная на потоке управления (Controlflow). Однако, эта модель не является единственно возможной. В некотором роде ее противоположностью является модель вычислений, управляемая потоком данных, или просто Dataflow. О ней я и хочу сейчас рассказать.

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

Извините фальстарт, это не я, это андроидный смартбук.

Когда мы только запускали облако, первой проблемой было «как нам получить консоль». Штатный механизм XCP поразумевает, что консоль рисуется с помощью VNCTerm, а желающий её увидеть должен сначала пойти в XenAPI, получить там session-id консоли, пойти на порт консоли, передать session-id, получить RFB, завёрнутый в HTTP, развернуть HTTP, вынуть RFB (он же VNC), отдать её локальному рендереру VNC (VNC-клиенту или java-апплету с тем же функционалом). При этом консоль закрывалась (сессия рвалась) при каждой перезагрузке виртуальной машины. Она рвалась даже при миграции виртуальной машины. Другими словами, это была технология, которая подразумевала «глянул одним глазком, починил ssh/iptables и забыл». Неудобно, медленно, сложно. Выкатывать такое в продакт совсем не хотелось.

И я залез в дебри serial-howto, console-howto и ещё несколько ужасных документов, рассказывающих о том, как правильно нужно конфигуриовать прерывания на ISA плате у мультикарт, а так же специфику настройки linux-2.2 для работы с оными. Параллельно изучалось устройство консоли в зене (внимательный читатель мог даже заметить, когда именно я более-менее разобрался в этом вопросе — я писал на хабре краткий обзор того, что происходит с консолью).

После этого пришла мысль: нужно писать своё, потому что готового чужого хорошего нет.

Сначала мы хотели взять хотя бы готовые компоненты и сделать из них своё. Я помню до сих пор ту замечательную схему, в которой мы планировали сохранять в БД вывод anyterm'а, делать двойное туннелирование последовательного порта с использованием UDP… Выглядело это, мягко скажем, неприглядно.

Потом пришла в голову мысль выпилить anyterm. Для этого нужно было посмотреть, как работают терминалки. Это было очень забавно и поучительно (желающие могут изучить исходный текст PuTTY). Главной проблемой в этом изучении было то, что они много рисуют на экран. Прямо в процессе обработки ввода. Отделить специфику DC от, собственно, того, что является консолью, было сложно.

Через некоторое время мы пришли к идее «нам нужен свой эмулятор терминала».
Задача казалась относительно простой, пока мы не прикоснулись к бездне, именуемой «escape-коды и типы терминалов...».

Пишущие машинки

Итак, в начале была пишущая машинка. В какой-то момент возникло желание совместить телеграф с пишущей машинкой. Так возник телетайп
Разумеется, инженерам, создававшим телетайп, не было никакого резона делать все с нуля. Они просто приделали коды к каждой клавише пишущей машинки. После некоторых боёв в стиле MS VS Netscape, был создан стандарт html5 на коды для оных машинок, то бишь телетайпов. Если мне память не изменяет, то это ASCII, где предусмотрены все комбинации клавиш, характерные для американской пишущей машинки. Включая код BELL, который, кстати, должен вовсе не делать BEEP, а делать «дзыньк», ибо у пишущих машинок был именно колокольчик, а не спикер.

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

Но вопрос остаётся тем же: как с годами программисты справляются с атакой всё новых технологий?

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

LLVM (Low Level Virtual Machine) — это универсальная система анализа, трансформации и оптимизации программ или, как её называют разработчики, «compiler infrastucture».

LLVM — не просто очередной академический проект. Его история началась в 2000 году в Университете Иллинойса, а теперь LLVM используют такие гиганты индустрии как Apple и Adobe. В частности, на LLVM основана подсистема OpenGL в MacOS X 10.5, а iPhone SDK использует GCC с бэкэндом на LLVM. Apple является одним из основных спонсоров проекта, а вдохновитель LLVM — Крис Латтнер — теперь работает в Apple.

В основе LLVM лежит промежуточное представление кода (intermediate representation, IR), над которым можно производить трансформации во время компиляции, компоновки (linking) и выполнения. Из этого представления генерируется оптимизированный машинный код для целого ряда платформ, как статически, так и динамически (JIT-компиляция). LLVM поддерживает генерацию кода для x86, x86-64, ARM, PowerPC, SPARC, MIPS, IA-64, Alpha.

LLVM написана на C++ и портирована на большинство *nix-систем и Windows. Система имеет модульную структуру и может расширяться дополнительными алгоритмами трансформации (compiler passes) и кодогенераторами для новых аппаратных платформ. Пользовательский фронтенд, как правило, линкуется с LLVM и использует C++ API для генерации кода и его преобразований. Однако LLVM включает в себя и standalone утилиты.

Для тех, кто не без оснований считает C++ не лучшим языком для написания компиляторов, с недавних пор в LLVM включена обертка API для OCaml.

Чтобы понять, что можно сделать с помощью LLVM, и на каком уровне придётся работать, давайте разберёмся,

Приветствую хабраюзеров, в этой статье пойдет речь о внутреннем устройстве компилятора LLVM. О том, что LLVM вообще такое, можно прочитать здесь или на llvm.org. Как известно, LLVM (условно) состоит из трех частей — байткода, стратегии компиляции и окружения aka LLVM infrastructure. Я рассмотрю последнее.

Содержание:

• Сборка LLVM
• Привязка к Eclipse
• Архитектура окружения
• LLVM API
• Оптимизация Hello, World!

Добро пожаловать в учебник «Создание языка программирования с LLVM». Этот учебник знакомит вас с созданием простейшего языка программирования, и при этом показывает, каким оно может быть легким и интересным, а также даёт вам начальные знания, которые вы затем сможете применить на других языках программирования. Код в этом учебнике также может быть использован в качестве стартовой площадки для ваших творений с помощью LLVM.

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

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

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






Начну с принципов, стоящих за хорошо организованной работой:

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

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

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

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

Иногда полезно представить граф в графической форме, так чтобы была видна структура. Можно привести десятки примеров, где это может пригодиться: визуализация иерархии классов и пакетов исходного кода какой-нибудь программы, визуализация социального графа (тот же Twitter или Facebook) или графа цитирования (какие публикации на кого ссылаются) и т.д. Но вот незадача: количество ребер в графе зачастую настолько велико, что нарисованный граф просто невозможно разобрать. Взгляните на эту картинку:



Это граф зависимостей некой программной системы. Он представляет собой дерево разбиения на пакеты (серые шарики — пакеты, белые — классы), на которое поверх наложены ребра зависимости одних классов от других. Чтобы не рисовать стрелки направления, ребра нарисованы в виде градиентных линий, где зеленый — это начало, а красный — конец ребра. Как видите, граф настолько визуально перегружен, что архитектуру программы невозможно проследить.
Под катом описание метода, решающего эту проблему.