Доброго времени суток, хабр!

Сегодня я хотел бы рассказать о прекрасном аналоге САПР AutoCAD под названием DraftSight, работающем под Linux (Ubuntu; Fedora, Suse или Mandriva; ArchLinux и пр.), Windows (x86, x86_64) и MacOS.
Данная САПР разработана компанией 3DS, широкоизвестной в узких кругах такими продуктами как CATIA, SIMULIA и др.

На хабре про эту САПР было упомянуто только в одной статье, да и то без должного уважения.

Основные возможности:

• позволяет создавать и редактировать файлы формата DWG (родной формат AutoCAD'а);
• интерфейс очень напоминает AutoCAD R14, так сказать классический вариант;
• САПР доступна бесплатно;
• имеется платная версия Premium для предприятий и для преподавателей.

Основные отличия платной версии от бесплатной (взято с сайта разработчика):

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

Самое, на мой взгляд, главное то, что САПР отлично подойдет для студентов, по долгу учёбы которым приходится много чертить. Этот инструмент превосходно заменяет AutoCAD и бесплатен для индивидуального пользования.

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

Добро пожаловать под кат.

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

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

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

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

Далее описание того, как я это сделал.

По роду своей деятельности я нередко становлюсь свидетелем «священных войн» между коллегами-программистами на тему, какую же систему контроля версий выбрать для того или иного проекта. Роль системы контроля версий особо остро ощущается в случаях разработки и поддержки проектов с длинной историей. Вариантов инструментов много, но я хочу сконцентрироваться на двух, на мой взгляд, наиболее перспективных: Mercurial и Git. Далее попробуем рассмотреть возможности обеих систем с позиции их внутреннего устройства.

Недавно, просматривая один из своих любимых англоязычных блогов, я наткнулся на статью Дэна Фармера (того самого, что создал один из первых сканеров уязвимостей в истории), название которой можно (пусть несколько вольно) перевести как «ИИУП: паровозик отправляется в АД».

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

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

Игра Oil Rush

В данной статье, состоящей из двух частей, речь пойдёт об использовании возможностей процедурных генераторов при создании контента для компьютерной игры Oil Rush и бенчмарка Valley (выйдет в феврале), разработанных на нашем собственном движке Unigine.

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

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



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

Однако, происходит некоторая подмена причин этого знакомства. Да, эта область в чем-то похожа, в первую очередь наличием понятий “требования”, “проектирование”, “проект”, “строительство” (construction), “контроль качества”, “человеко-часы”, “работы”, “сроки”, а сам процесс развивается от экономической потребности и идеи до некого конечного продукта. Но основная причина того, что строительство является хорошей аналогией в том, что это наглядная аналогия.

(В качестве иллюстрации фотография проекта А.Гауди «Sagrada Familia», степень выхода которого за сроки и бюджет до сих пор не могут даже приблизительно оценить)

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



Странно, но методики, которые родились непосредственно в области разработки ПО совсем не похожи на пришедшие извне.

Например достаточно простой SCRUM, описание которого вполне можно уместить на листок A4, но которым пользуется CERN. Или Agile, который можно описать десятом абзацев где содержатся весьма общие и идеалистические принципы в соответствии с которой был сделан GitHub и много других клевых штук. Можно ли их использовать в строительстве? А при создании самолетов?

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

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

Вы едете в лифте. Перед вами экран с информацией. Присмотримся к нему повнимательнее. Для начала проверим, куда идёт кабель. Если открыть люк сверху, то можно увидеть, что прямо на крыше лифта лежит системный блок в специальном исполнении с некоторой дополнительной защитой. И без вентиляторов. Там стоит какая-нибудь довольно простая Windows (возможно — embedded-версия, поставленная ещё на заводе) и Wi-Fi модуль. Где-то неподалёку в шахте найдётся и роутер, подключённый кабелем к локальной сети.

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

Это — часть системы дистрибуции контента. Конкретно этот узел может ездить вместе с лифтом во Владивостоке, а админить его может человек, сидящий где-то далеко, например, в Москве.

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

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

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

Формы состоят из самых разных элементов интерфейса. Если вы не знаете, как правильно с ними обращаться, вы можете сильно усложнить заполнение форм. Чаще всего ошибаются, применяя выпадающие списки (select menu).

Когда использовать

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

GizmoSphere и AMD представили высокоинтегрированную плату Gizmo Board для независимых разработчиков, производителей встроенных систем и гиков.

Gizmo Board представляет собой четырехдюймовый квадрат текстолита, заряженный двухъядерным x86-процессором G-T40E, который работает на частоте 1 ГГц, и GPU Radeon 6250. Эти два компонента в таком компактном дизайне обеспечивают приличную вычислительную мощь, правда всего 1 ГБ оперативной памяти DDR3, распаянной прямо на плате, возможно существенно ограничивают ее. Устройство способно работать под Android, Linux или Windows и снабжено следующими коммуникационными разъемами: SATA, Ethernet, USB, VGA, Audio, PCI, PCIe, а так же кучей выводов GPIO.

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

Однако, в отличие от работоспособности кода, которую можно оценить с помощью выполнения проверочных тестов, качество кода не является простой оценкой TRUE или FALSE. Более того, под качеством кода понимается набор субъективных оценок восприятия кода другим человеком. Однако давайте всё-таки попробуем как-то формализовать задачу оценки качества, и, при возможности, дать способ автоматического выполнения этой задачи.

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

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

Каждый мой рабочий день на протяжении нескольких месяцев начинается с того, что я открываю интеллект-карту с многообещающим названием «Задачи». Карта постоянно развивается, обрастает новыми веточками и идеями. Несколько месяцев назад этот способ систематизации всего на свете пришёлся мне по вкусу, показался очень естественным и окончательно въелся в сознание.
Интеллект-карты пригодятся, чем бы вы ни занимались. Особенно, если ваша деятельность связана планированием, проект-менеджментом, организацией мероприятий, копирайтингом, проектированием сайтов и т.п. В чём фишка mindmaps, что стоит описывать с помощью интеллект-карт, как они помогают в работе, и чем хороша свободная программа FreeMind — читайте под катом.

Недавно наткнулся на ошибку в Android приложении Яндекс.Метро. Если бы был чемпионкой мира по синхронному плаванию, то обязательно спросил бы: «Кто создавал программу „для галочки“? Кто работал „на отшибись“? Кто слабое звено?». Недоумение вызывала не сама ошибка, а то, что она попала в приложение и всё ещё не исправлена.

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

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

В статье же мы будем рассматривать распространённые приложения, которые протестировать может любой участник команды. Давайте проведём небольшой эксперимент. Если у вас нет Android устройства, то попросите минут на десять у коллег или друзей. Скачайте приложение Яндекс.Метро и попробуйте его протестировать. Интересует актуальная на текущий момент версия 1.63 от 02.11.2012 сборка 159 (на Google Play стоит дата 21.01.2013). Для корректности проверки предлагаю снять галочку «Автообновление» в настройках Google Play.

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

Эта же ошибка может проявить себя не так явно:

Это перевод нашумевшей статьи с TechCrunch от Джеймса Альтушера — инвестора, программиста, автора статей и немного предпринимателя. Его последние книги: Я был слеп, но теперь я вижу и 40 альтернатив колледжу. Читайте его в Twitter @jaltucher.

Люди читают TechCrunch потому, что они хотят что-то создать, они не желают следовать приказам всю жизнь и хотят финансовой свободы. Давайте начистоту. Эти три пункта кажутся притягательными. Да благословит Вас Бог. Надеюсь, что когда Вы их обретете, Вы сможете сохранить их. Большинству людей (например, МНЕ), нужно просто немного покататься на американских горках, потому что мы тупые. Но некоторые люди умные.

«И эти дурацкие иконки! Пиктограмма — это знак, который ни на одном человеческом языке невозможно объяснить. Не зря же появилась речь!»
Джеф Раскин.

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