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

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

Разработка ПО – область, подверженная рискам. В нашей сфере при наступлении одного или нескольких рисков, срок поставки рабочей версии может сдвинуться не на привычные и комфортные 10-20%, а на все 150-300%. И надо признаться, что это далеко не предел.

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

До Agile и XP вся ответственность за работу с рисками ложилась на менеджеров. В гибких методологиях разработчики гораздо больше вовлечены в процесс и делят ответственность с менеджерами. Однако, принципы XP и Agile – больше методологические, чем технологические. Я думаю, что с рисками эффективнее работать комплексно на всех уровнях, в том числе на самом низком уровне, т.е. во время проектирования и написания кода.

Почему об этом следует думать разработчику, если есть менеджер?

1. Не секрет, что если факап случится, менеджмент примет единственное «супер-умное» решение: «давайте поработаем сверхурочно и в выходные»
2. Премии сотрудники получают тоже обычно за в срок сданные, а не за проваленные проекты
3. Чувство сделанного дела, в конце концов. Гораздо приятнее сдать проект во время и видеть улыбку клиента, чем с опозданием в полгода отвязаться от «трудного ребенка»

С моей точки зрения спокойная рабочая обстановка вместо авралов и бонусы – неплохая мотивация, чтобы начать заботиться об этом.

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

Дорогие Хабролюбители, всем привет! Не откроем Америку если скажем, что существуют сотни плагинов и библиотек, которые облегчают специализированные задачи, связанные с построением современных web интерфейсов. Angular один из них, про его производительность писалось много и в большинстве случаев даются рекомендации чего не нужно делать, чтобы все было хорошо.

Основной аргумент сторонников — медленно работают неправильные приложения, а вот правильные не должны содержать более 2000-3000 элементов. Если содержит больше значит что-то не так. См. например http://iantonov.me/page/angularjs-osnovy.

Аргумент в общем вполне здравый, но всегда есть ситуации, когда нужно написать «неправильное» web приложение потому, что такие требования. В этой статье мы решили рассказать как раз про такую задачу, и как мы ее решили. На наш взгляд статья будет полезна в большей степени профессиональным веб разработчикам. Итак, наша задача была сделать календарь для системы бронирования для одного спортивного клуба. Календарь отображает семь 12–часовых блоков, каждый день из которых разделен на 15 минутные интервалы. В блоке может быть от 2-х до 10 DOM элементов. Вроде ничего не предвещало беды, верхняя граница ~3000.

Когда возникает идея создать что-нибудь полезное, обычно очень хочется сделать прототип (или версию 1.0) как можно скорее. Для кого-то, видеть быстрый результат — это хорошая мотивация, чтобы развивать идею дальше; для других — главное «начать», всем известная истина, что доделывать/переделывать готовое намного легче, чем писать с нуля. Итак, в процессе очередного чаепития и обсуждения финансовых рынков, у нас появилась идея создания легкого сервиса для обмена идей и новостей, а также определения текущей ситуации на фынансовых рынках (т.н. тренды) — ведь зная тренды, можно более эффективно торговать.
В требованиях были: веб сервис, мобильная версия (желательно app), легкая коллективная админ-часть, и простой интерфейс.
Как у нас получилось мега-быстро «слепить» одновременно и веб и мобильную версию приложения CxInvestor и пойдет речь в этой статье.

Разработка

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

В ответ вот на эту статью, про выбор покупки серверов или оптимизации.

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

Как обычно происходит и почему

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

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

Зачем это все надо

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



Но возникает проблема для тех, у кого нет дома NAS или чего-то подобного, а смотреть контент с ПК на других устройствах, поддерживающих DLNA хочется. Под Linux существует множество различных DLNA-серверов, но оптимальным, все же, является MiniDLNA. И тому есть несколько причин. Во-первых, это типичный Unix-way: этот сервер является именно DLNA-сервером, а не комбайном с кучей свистелок, при этом контент без проблем воспринимается на любом устройстве. Даже телевизоры Samsung со своим AllShare прекрасно подключаются к нему. Также можно отметить и замечательную скорость работы и нетребовательность к ресурсам этого сервера.

И все бы было хорошо, но вот в с помощью команды

sudo apt-get install minidlna

установить его не получится — нет его в репозитарии.

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

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

Возникла передо мной сегодня задача генерации GET-параметров и всего URL в целом, на стороне клиента, прям вот щас, без возможности «поговорить» с сервером. Сразу оговорюсь, про этот пост я узнал вот прям перед написанием данной статьи ибо сначала закончил писать, а потом уже прибег к поиску, да и пост тот — не со всем про то же самое, что у меня.

Итак, к делу.

Задача и проблемы

Проблемы — те же что и в посте, который я привел выше:

• Невозможность использовать window.location для «приготовления» URL;
• Нельзя работать сразу с несколькими window.location в силу политики безопасности браузеров;
• Отсутствие известных готовых решений ( да и сейчас, уже апосля, я не нашел подобного кода )

Задачи которые я поставил перед собой:

• Удобный синтаксис
• Возможность как читать части URL так и изменять их
• Работа с GET-параметрами
• Кроссбраузерность и универсальность

Писал я на чистейшем JavaScript, причем без использования prototype.__defineGetter__ или prototype.__defineSetter__ в угоду кроссбраузерности ибо IE < 9 такого не умеет. Более подробно про getters/setters написано в этом посте.

Для тех кому интересно — сядем разберем, а кому надо готовое решение — милости прошу в конец поста, ссылки на скачивание — там.

Приступим! Раньше сядем — раньше выйдем.

Введение

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

В этой статье я расскажу о следующем:

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

От переводчика:

Привет, Хабр! Мы мы продолжаем делится с сообществом полезными материалами о разработке и дизайне. В этот раз команда TrackDuck подготовили перевод статьи Jeff Dickey о Angular, которая нам очень понравилась и в свое время заставила пристальней присмотреться к Gulp. Эта статья будет полезна разработчиками, которые хотят сэкономить время на рутинных операциях и построить качественные процессы при разработке веб-приложений. Мы активно используем Angular для разработки собственного продукта для визуального комментирования веб-сайтов, поэтому готовы ответить в комментариях на интересующие вас вопросы!

Я использовал Angular в довольно большом количестве приложений и видел много способов структурирования приложений с использованием этого фрэймворка. Сейчас я пишу книгу о проектировании Angular приложений c использованием MEAN стека, и больше всего исследований я провел в этом направлении. В итоге я остановился на довольно оригинальной структуре приложения. Я считаю, что мой подход более простой чем тот, что предложил Burke Holland.
Прежде чем начать, я хотел бы рассказать о существующем подходе к реализации модульности в Angular.

В статье будет рассмотрена маршрутизация внешнего IP-адреса внутрь локальной без пробрасывания ethernet-шлюза и переписывания адресов в iptables. В итоге на сетевой карте внутреннего сервера будет один правильный внешний IP-адрес, внутренние IP-адреса будут отсутствовать.

Доброго времени суток дорогой %username%!
Хотелось бы поздравить с праздником всех админов и в честь этого накатило на меня написать пост. По роду своей деятельности (*nix админ), ко мне обращаются знакомые с различными просьбами о помощи по серверам. Обычно просьбы в духе — у нас стал тормозить сайт, или что-то у нас повисло и т.п. Очень часто, проблемы возникают из-за действий программистов, которые не всегда понимают что делают, либо не понимают последствий того, что они делают. Посмотрев на это все, я решил поделиться с вами некоторыми случаями и наставлениями.

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

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

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

Недавно я открыл для себя удобство отложенного чтения — когда заинтересовавшую статью в сети можно прочитать в любое время, комфортно расположившись c любимым девайсом на диване / пляже / под одиноким деревцем на тропе, ведущей к базовому лагерю у подножья Эвереста. И хотя проприетарных решений для этого хватает (Instapaper, Pocket, Readability), душа настойчиво требовала OpenSource. И вот к какому решению я пришёл после исследования возможных вариантов.

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

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

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

Краткий спойлер содержимого: VCS, репозиторий исходного кода, code-review, build-сервера, CI, таск-трекер, вики, корпоративный блог, функциональное тестирование, репозиторий для пакетов, система управления конфигурацией, бэкапы, почта/jabber.

Картинка с фрагментом обсуждаемой инфраструктуры:

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

Хочу представить программную платформу автоматизации для дома на базе Node.js, которую можно скачать со всеми исходниками и установить прямо сейчас практически одним кликом (Windows) или одной командой (Linux/Debian).

Во многих компаниях, как и моей, есть много проектов и продуктов. И у продуктов бывают веб-интерфейсы, чтобы этими продуктами как-то манипулировать. В нашем случае это простенькие RESTful веб-сервисы, а поверх них ещё более простенькие веб-странички с формочками и кнопочками. Все эти веб-странички до того похожи друг на друга, что возникла мысль написать унифицированный продукт, который бы спрашивал сервер о поддерживаемых сервисах, и получал бы полное описание параметров к этим сервисам, так чтобы можно было нарисовать те самые простенькие формочки. То есть, веб-сервисы должны описывать себя, достаточно исчерпывающе, чтобы наш клиент мог построить GUI для них, и ничего не надо было бы делать руками. Как раз такая картинка гуглится по запросу «REST»:

Предисловие

Проснулся я сегодня с мыслью, что огромное количество инструкций по настройке NAT советуют использовать строку вида:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Многие понимают проблемы этой конструкции, и советуют добавлять:

iptables -A FORWARD -i ppp0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT

Но, зачастую, забывают задать таблице FORWARD действие DROP по умолчанию, или добавить правило REJECT в конец таблицы.
На первый взгляд, вроде бы, все кажется нормальным. Однако, это далеко не так. Дело в том, что если не запретить маршрутизировать трафик из WAN-порта в WAN-порт, кто-нибудь из вашей WAN-сети (предположим, что провайдер садит весь подъезд в одну /24) может маршрутизировать трафик через вас, просто прописав ваш IP в качестве шлюза. Все современные SOHO роутеры это учитывают, а вот неопытный администратор, который делает роутер под обычным linux, может не знать или забыть об этом. В подсети моего провайдера таких роутеров не оказалось, и мой план по захвату мира провалился. Однако, статья совсем не об этом.

Магические двоеточия

Как вы, может быть, знаете, многие современные программы и сервисы биндятся на IP :: (два двоеточия), а не на 0.0.0.0, как было раньше. IPv6 адрес :: значит то же самое, что и IPv4 0.0.0.0, т.е. «слушаем все интерфейсы». Многие считают, что если программа слушает ::, то этот сокет может принимать только IPv6-соединения, однако это далеко не так.
В IPv6 есть так называемое отображение IPv4-адресов в IPv6 диапазон. Если программа слушает сокет ::, а к ней обращаются из IPv4-адреса 1.2.3.4, то программа получит соединение с адреса ::ffff:1.2.3.4. Этого можно избежать, сделав:

sysctl -w net.ipv6.bindv6only=1

Но это нужно далеко не всегда, т.к. обычно удобно, что программа слушает один сокет, а получать соединения может по двум протоколам сразу. Практически во всех дистрибутивах, IPv6-сокеты ведут себя именно так, т.е. bindv6only=0.

Центр сертификации GlobalSign начал раздавать бесплатно SSL-сертификаты проектам Open Source, которые соответствуют критериям. Это хорошая возможность для тех проектов, до сих пор не имеющих сертификата, получить его. Сертификат действует бессрочно, то есть пока проект соответствует заявленным требованиям.

Требования:

• Свободная лицензия из списка Open Source Initiative.
• Действующая поддержка проекта.
• Соответствие требованиям благонадёжности.
• Правильная конфигурация SSL (после выдачи сертификата) с получением высшего балла “A” при проверке в SSL Checker.
• Соглашение со стандартными условиями.
• Сайт не должен использоваться в коммерческих целях.