Вступление

Сбор требований – это один из самых важных этапов при создании информационных систем и интернет-сайтов в частности. От того, насколько точно и полно будут учтены все пожелания заказчика в процессе проектирования сайта, и будет зависеть итоговый результат: получим ли мы сайт «для галочки» или это будет эффективный инструмент бизнеса, который будет приносить прибыль своему владельцу.
Предлагаемая методика сбора требований используется в нашей компании при разработке несложных клиентских сайтов, реализуемых по каскадной модели (Waterfall). Методика позволяет менеджеру по продажам организовать эффективный сбор требований и написать на его основе «Техническое задание», по которому разработчик будет создавать сайт.
Замечу, что ничего не мешает использовать данную методику сбора требований и в Agile–разработке, в частности, для создания первичного бэклога.
В данной статье я концентрировался именно на содержательной части сбора требований, а не на вопросах внедрения сбора требований в бизнес-процессы компании или на то, как строить диалог с клиентом – это тема для отдельного разговора.

Так или иначе, практически каждый из нас использовал в своей жизни технику интеллект–карт или Mind Mapping. Это всего лишь простая радиальная схема, но с правильным подходом ее можно превратить в мощный инструмент аналитики и синтеза информации, который всегда под рукой и достаточно прост в использовании. И что самое интересное, освоение техники настолько естественно для нашего мозга, что занимает всего лишь несколько минут…

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



Тогда понадобился год, чтобы прочитать в десять раз больше бумаги и сделать выборку, которая оказалась неожиданно полезной многим. Вот результаты ещё одного года — ещё N+2 книги для бизнеса, которые реально помогают.

С технической точки зрения юнит-тесты – это очень простой инструмент, основанный на паре несложных концепций: (1) тестируемый класс, (2) набор тестовых методов, завернутых в некоторый класс и (3) набор методов, с помощью которых можно удостовериться в том, что состояние тестового класса соответствует (или не соответствует) некоторому значению.

Это очень простая штуковина, которая может кардинальным образом повлиять на процесс разработки в целом. С одной стороны существует TDD (“test-first approach"), при котором тесты «драйвят» не только процессом кодирования, но и процессом проектирования (т.е. дизайном системы). С другой стороны существуют разработчики с противоположной точкой зрения, которые считают юнит-тесты пустой тратой времени, потому что они не приносят никакой ценности пользователю.

Не только XSS…

Последнее время многие обращают внимание на уязвимости ПО, используемого в банковском секторе: в частности, недавно прошумела новость об уязвимостях класса XSS на веб-сайтах различных банков. Общественность негодует, и СМИ шумят. Но ведь банки богаты не только веб-составляющей. Начиная с конца 2000-х я собирал уязвимости в модулях ActiveX, которые банки гордо раздают своим пользователям, а именно клиентам системы дистанционного банковского обслуживания (ДБО). Раз в год я брал одну или две системы и ковырял их. Начиная просто так, любопытства ради (начал это дело, еще будучи сотрудником банка) и продолжая уже из исследовательского интереса. В итоге за 3–4 года я выявил уязвимости в системах от таких производителей, как BSS, Inist, R-Style, ЦФТ. Под катом находится информация об одной такой уязвимости. Большая часть описания уделена созданию простенького эксплойта для выполнения произвольного кода на стороне клиента (Windows7, IE +DEP/ASLR). Возможно, это будет полезно тем, кто хотел бы понять принципы эксплуатации старых ‘strcpy’ багов и создания ROP-эксплойтов.

Я собираюсь сделать Java-веб-приложение (да, это будет Java, по некоторым причинам, которые сейчас озвучивать не хочу). В процессе работы, я оцениваю кучу J2EE portlet-enabled JSR-compliant MVC role-based CMS web service application container фреймворков.

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

Давайте представим, что я решил сделать шкафчик для специй.

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

Несмотря на почетный возраст, конференция живет и развивается, за что огромное спасибо организаторам: Ассоциации «РусКрипто» и АИС. В свое время именно на этой площадке я обкатывал свои идеи, которые позже привели к появлению Positive Hack Days. Именно тут прошел первый масштабный CTF под руководством Дмитрия Евтеева. В общем, отношение к «РусКрипто» у меня крайне теплое и в некоторой степени даже ностальгическое.

В этом году конференция проходила на площадке загородного отеля «Солнечный». Кстати, на веб-сайте отеля уютно расположилась mobile malware – расценил это как тест на профпригодность =)

«Chicago Boss — бескомпромиссный веб-фреймворк, любимый дизайнерами, инженерами и этим парнем с пейджером.» — © chicagoboss.org

«Erlang — язык для создания отказоустойчивых распределенных приложений. Это — один из немногих функциональных языков, который давно и успешно применяется на практике. Например — в телекомах (Ericsson AXD-301 switch), банковских системах, системах автоматизации, высоконагруженных веб-приложениях (Facebook Chat). При этом Erlang — продукт с открытым исходным кодом и распространяется бесплатно.» — говорит нам сайт русскоязычного сообщества Erlang.

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

По заверению обоих разработка веб-приложений на базе этого фреймворка ничуть не медленнее разработки на тех же рельсах (Ruby on Rails). А в чем-то даже быстрее. Я с функциональным программированием до этого особо знаком не был, но под давлением товарища решил попробовать. Хочу сказать, что опыт был весьма удачным и у меня получилось создать мой первый веб-сайт быстрее, чем год назад с тем же Ruby on Rails.

Пользователь eyeofhell недавно написал статью Python vs Ruby.
Знатный холивар получился. Не могу не поддержать. Сначала думал написать в комментарии — но ответ вышел слишком объемным.

Данная флеймообразующая статья призвана собрать в одном месте актуальную информацию по преимуществам Python над Ruby и Ruby над Python. Основываясь на собственном многолетнем опыте использования обоих языков, я постарался ограничить сравнение языками как таковыми и их стандартными библиотеками — сравнение web фреймворков, сред разработки и доступных библиотек не включены в статью, так как здесь и без меня немало копий сломано.

Почти год назад (6 апреля 2011) вышел новый федеральный закон об электронной подписи (ЭП) — N 63-ФЗ «Об электронной подписи» взамен старого ФЗ №1-ФЗ от 10.01.2002. Когда старый закон отменили, многие вздохнули с облегчением, уж больно он был неподъемен для коммерческого сектора. Теория и практика обращения с ЭП в этом топике.

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

Пролог

Почти полгода назад, 3 сентября 2011 года мы начали разработку кредитного сервиса Conpay.ru. Задача, поставленная перед командой, была определена очень просто: дать возможность покупателям интернет-магазинов приобретать товары в кредит. Но, не смотря на простоту в определении этой задачи, для ее решения нам пришлось на полгода выпасть из нормальной жизни и с головой уйти в мутную воду финансовых стартапов. На старте проекта команда состояла всего из 3 человек: полтора программиста и полтора менеджера. Тем не менее, даже поняв сложность задачи и ограниченность собственных ресурсов, мы продолжали работу на энтузиазме и вдохновении (и бодреньких книжках типа Фрайда и Кавасаки). И вот, наконец, после нескольких месяцев трудов и испытаний нам удалось запустить сервис.

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

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

Как и у многих пользователей macbook в моей жизни настал момент когда мой MagSafe коннектор перестал корректно работать(только под определенным углом), а затем и вообще перестал заряжать.

Немного поискав по рунету нашел несколько инструкций по ремонту старых MagSafe адаптеров, про ремонт Г-образного толком нечего не было. Решил ремонтировать сам, так как стоимость нового у нас в районе 80$.
Подвожу итог: я сделал свой и позже еще 2 купленных по 15$ за каждый (один теперь на работе, 2-й который был почти новый подарил). Небольшая инструкция по ремонту внизу:

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

Что такое Sinatra

Sinatra — маленький, но довольно интересный DSL (Domain-specific language) фреймворк, написанный на Ruby. В отличие от Ruby on Rails он не следует типичному паттерну MVC (Model — View — Controlller). Sinatra создавался для того, чтобы «программист смог быстро создать веб приложение, написанное на Ruby с минимальными усилиями.

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

gem install sinatra

Также нам понадобится гем под названием Shotgun. Нужен он нам для того, чтобы лишний раз не перезагружать сервер вручную. Shotgun сделает это за нас. Давайте установим его:

gem install shotgun

Ну вот и всё! Всё необходимое для работы у нас есть. Настал момент для творчества. Приступим…

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

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

1.

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

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

Если оглядеться вокруг, то может сложиться впечатление, что отрасль разработки ПО шагает такими громадными шагами, что угнаться за ней нет никакой возможности. И если рассматривать всю отрасль в целом, то действительно это так и есть. Как-то сразу вспоминается старина Брукс со своим «Мифическим человеко-месяцем», когда он в заключении к своей книге пишет о том, как изменилась индустрия ПО в середине 90-х по сравнению с 50-ми годами. В те далекие годы (да, 90-е тоже уже далеки, так что уж говорить за эпоху зарождения индустрии сорока годами ранее) можно было прочитать все журналы (!), компьютерной тематики, которые выходили в свет. Сейчас же ежемесячно появляется десятки книг только по одной из популярных технологий, а количество статей просто не поддается счету.

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

Предисловие

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

Введение

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

Однако, изучение Ruby on Rails является достаточно простым занятием. Это невероятно мощный фреймворк, который имеет огромное сообщество, продвигающее его вперёд. Итак, у нас возникает вопрос: какой способ изучить Rails является лучшим? Вот он — план занятий.

Статья изначально публиковалась для личного блога, но думаю те кто начинают изучать Ruby, или просто хотят написать GUI к приложению сочтут ее полезной.

Вступлений не будет. Тема сегодня — Shoes. Такой небольшой kit, для создания GUI к приложениям на Ruby. Впервые я о нем них услышал, когда пытался понять, как сделать на руби нечто графическое. Ответ пришел сразу, причем в двух(а то и трех вариантах):

• Qt
• wxWidgets
• Tk
• Shoes

Посмотрел пункт первый, затем второй. Узнал, что множество из ныне живущих популярных GUI-приложений на C++ имеют под собой Qt-основу :) В общем, вызнал много полезного да и вообще позитивного. На шузы (нравится их так называть) я почти не смотрел, а зря.

Перевод статьи Джейсона Фрида (Jason Fried) "Why I Run a Flat Company". Джейсон — один из основателей компании 37signals и соавтор книг "Getting Real" и "Rework".

Несколько месяцев назад в компании 37signals, которую я возглавляю, случилось необыкновенное событие: мы расстались с одним из наших сотрудников. Казалось бы, что в этом необычного? Но дело в том, что в нашей компании подобное происходит крайне редко. За 11 лет работы мы потеряли всего лишь пять человек, причем один из них вернулся к нам семь лет спустя.

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