Денежная инфекция поражает воображение. © Павел Шарпп
2013 год. Пришло время оценить результаты работы за прошлый год. Сделано много — похвалиться нечем.
CEO прочитав какую-то из очередных «умных» книг (а может и посетив семинар) понял в чем у нас загвоздка. Появились понятия о капитализации, экзитах, опционах, акциях, бюджетах, прогнозах, гипотезах и об инвестиционных раундах.
Главная польза капитала не в том, чтобы сделать больше денег, но в том, чтобы делать деньги ради улучшения жизни. © Генри Форд
… начало 2011- середина 2012 год.
Действующая схема заработка плавно приходила к своему концу «генетического кода», а именно к закату эры «золотых дровосеков». Самым лучшим решением казалось, взять все дочерние сервисы, которые использовались для своих целей и довести их до ума разума переделать под внешний рынок. В обратном случае придется все сложить в самый дальний угол и оставить там гнить да покрываться пылью.
Привет! Откладываем ноуты в сторону – код никуда не убежит. Сегодня мы поговорим о самой страшной перспективе карьеры программиста, которая может заставить вздрогнуть даже бывалых прогульщиков IT-вузов и поспешно начать допиливать несданный код. Нет, вы не угадали, это не касса МакДоналдса, это техподдержка. О ней, любимой, и пойдёт сегодня речь.
Итак, это обзор. Точнее – обзор показателей доступности техподдержки, ещё точнее – техподдержки ключевых игроков рынка IT-продуктов в сфере сетевой безопасности и контроля нежелательного доступа.
Примечание от переводчика. Изначально эта статья была опубликована на сайте AltDevBlogADay. Но сайт, к сожалению, прекратил своё существование. Более года эта статья оставалась недоступна читателям. Мы обратились к Джону Кармаку, и он сказал, что не против, чтобы мы разместили эту статью на нашем сайте. Что мы с удовольствием и сделали. С оригиналом статьи можно познакомится, воспользовавшись Wayback Machine — Internet Archive: Static Code Analysis.
Поскольку все статьи на нашем сайте представлены на русском и английском языке, то мы выполнили перевод статьи Static Code Analysis на русский язык. А заодно решили опубликовать её на Хабре. Здесь уже публиковался пересказ этой статьи. Но уверен, многим будет интересно прочитать именно перевод.
Самым главным своим достижением в качестве программиста за последние годы я считаю знакомство с методикой статического анализа кода и ее активное применение. Дело даже не столько в сотнях серьезных багов, не допущенных в код благодаря ей, сколько в перемене, вызванной этим опытом в моем программистском мировоззрении в отношении вопросов надежности и качества программного обеспечения.
Читать полностью »
Занимаясь чем-то профессионально, мы постоянно принимаем решения. Большие и маленькие, важные и не очень. От того насколько правильно мы их принимаем, зависит успех всех нашей деятельности.
Когда речь идет о разработке ПО или развитии стартапа – от решений ключевых сотрудников зависит как коммерческий успех проекта, так и благополучие, эффективность и боевой дух команды. Ошибки здесь выявляются далеко не сразу и обходятся очень дорого.
Сейчас мы живем в эру платформ. А это значит, что даже принтерам нужны их собственные магазины приложений. Поэтому Samsung разработала набор разработчика, благодаря которому можно создать приложения для принтеров на базе Android.
Читать полностью »
Сегодня мир управления проектами разделен на два лагеря: остроконечников и тупоконечников. Конечно, у нас не все так запущено, как у великого Джонатана Свифта. Но все же перед руководством любого проекта еще до начала работ всегда встает проблема: как разбить яйцо, с острого или тупого конца выбора программного обеспечения: основанного на классических или на современных гибких методиках. Выбор стоит именно так: либо одно, либо другое.
Иллюстрация: Alamy/PHOTAS
Рис. 1. Заседание руководства проектом Остроконечники и тупоконечники
Воспользуемся сравнительным анализом существующих методик управления проектами, изложенным в монографии Роберта Высоцкого «Адаптивное управление проектами: традиционные, гибкие и экстремальные методики». Седьмое издание этой книги не так давно стало доступным англоязычной аудитории. Насколько мне известно, она еще не переведена на русский язык. А жаль, книга замечательная, видимо не зря на американском Амазоне у нее 4ый рейтинг среди литературы по Аджайлу.
Читать полностью »
Некоторое время назад обратил свое внимание на артефакт Концепция продукта (product vision) методологии разработки программного обеcпечения RUP (Rational Unified Process) и обнаружил, что отправной точкой разработки программного продукта является выявление проблемы, на решение которой нацелен продукт.
Аналогичный подход существует и в отечественной практике – так в ГОСТ 34.601-90 говорится, что на стадии Формирование требований к АС (автоматизированной системе) производится «выявление проблем, решение которых возможно средствами автоматизации».
В настоящей статье хочу поделиться с читателями своими выводами касательно природы проблемы, ее важности и отношении к разработке программного продукта.
Читать полностью »
Проектирование корпоративного веб приложения, как и любого другого приложения, стоит начать с определения первоначальный целей и области решаемых задач. Создать реестр заинтересованных лиц.
На следующем этапе необходимо собрать требования к приложению, которое необходимо разработать. Уточнить цели и область решаемых задач и построить иерархическую структуру работ.
Рассмотрим отдельно задачу построения иерархической структуры работ. Каждое web-приложение можно представить в следующем виде:
Жив или мертв софтостроительный бизнес? Как завести полезные знакомства с коллегами по отрасли, будучи интровертом? Что общего между посещением конференции и свиданием с девушкой? Денис Журавлев, независимый разработчик программного обеспечения, рассуждает об этих и других вопросах так интересно, что мы не удержались от публикации его размышлений в нашем блоге. Собственно, вот:
Наша небольшая компания придумывает и разрабатывает собственные программные продукты и самостоятельно продает их по всему миру. Но сегодня я не буду говорить о наших продуктах, даже не назову их. Сегодня я хочу поговорить о другом.
В различных онлайн- и офлайн- сообществах меня часто спрашивают о том, надо или не надо посещать конференцию ISDEF (2014.isdef.org), на которой уже почти пятнадцать лет подряд традиционно собираются независимые разработчики программного обеспечения, и какая от этого польза. Некоторые спрашивают с искренним любопытством, некоторые — с легким саркастическим скепсисом, некоторые — с нескрываемой желчной язвительностью.
С одной стороны, я не основатель и не член правления ISDEF и мне нет резона восхвалять ассоциацию, зазывать всех как можно быстрее вступить в нее и в обязательном порядке посещать ее конференции. Поэтому иногда хочется просто махнуть рукой на скептиков, не спорить и сказать: “Да как тебе угодно”.
С другой стороны, как член этого профессионального клуба я, конечно же, заинтересован в том, чтобы ISDEF продолжал жить, развивался, менялся вслед за отраслью и пополнялся свежей кровью. Поэтому прежде чем махнуть рукой, я все-таки попытаюсь сначала разъяснить свою личную субъективную позицию.
Чтобы не растекаться мыслями по древу, я просто собрал самые популярные вопросы, которые я слышал про ISDEF, и постарался ответить на них.
Читать полностью »
