Приглашаем вас присоединиться к бесплатной онлайн-трансляции конференции ALM Summit, которая будет проходить 6 февраля 2014 г. с 10:00 (МСК).
Присоединившись к саммиту, вы сможете узнать все об организации процессов разработки и управлении жизненным циклом программного обеспечения, а также познакомитесь с лучшими индустриальными практиками внедрения ALM.
Наиболее внимательного онлайн-зрителя ждет сюрприз! Во время пленарного заседания Брайан Келлер овучит цифру использования Visual Studio Online в России за 2013 год. Тот, кто напишет первым эту цифру в твиттере с хештегом #almsummit, получит Visual Studio 2013 Premium с подпиской MSDN!

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

Методику составления рейтинга мы позаимствовали у Jurgen Appelo. Алгоритм подсчёта базируется на пяти различных критериях: количество отзывов Amazon, число отзывов GoodReads, средняя оценка Amazon, средняя оценка GoodReads, а количество дней, прошедших с первой публикации. Это означает, что этот список показывает вам смесь из самых популярных, лучших по оценкам, и (относительно) новейший книги в этой категории.

Данный список книг мы попросили прокомментировать двух экспертов:

Борис Вольфсон. Технический директор компании HeadHunter.

Андрей Ребров. Agile Engineering Coach компании ScrumTrek.

Даже если вы никогда в жизни не думали, что занимаетесь тестированием, вы это делаете. Вы собираете свое приложение, нажимаете кнопку и проверяете, соответствует ли полученный результат вашим ожиданиям. Достаточно часто в приложении можно встретить формочки с кнопкой “Test it” или классы с названием TestController или MyServiceTestClient.



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

Оно выполняет свою задачу, но сложно для автоматизации. Как правило, тесты требуют, чтобы вся или почти вся система была развернута и сконфигурирована на машине, на которой они выполняются. Предположим, что вы разрабатываете web-приложение с UI и веб-сервисами. Минимальная комплектация, которая вам потребуется: браузер, веб-сервер, правильно настроенные веб-сервисы и база данных. На практике все еще сложнее. Разворачивать всё это на билд-сервере и всех машинах разработчиков?

Стив Бланк — гуру в области стартапов, основоположник концепции клиентоориентированной разработки, автор культовых книг — The Four Steps to the Epiphany и The Startup Owner's Manual -, фаундер восьми стартапов. Данная статья раскрывает причины, по которым стоит отказаться от традиционных подходов к построению стартапа.

После 20 лет работы в стартапах, я решил остановиться и посмотреть на модель разработки продукта (Product Development Model), которой следовал: понять, почему она была неуспешной в том, что касается нашей работы «вне офиса» — продаж, маркетинга и развития бизнеса.

У каждого стартапа есть какая-нибудь методология по разработке продукта, его запуску и управлению жизненным циклом. В идеальном случае, эти процессы содержат детальные планы, чек-пойнты и майлстоны для каждого этапа вывода продукта на рынок: определение размера рынка, оценка продаж, разработка маркетингово плана, приоритезация фич продукта. Но в конце концов, не смотря на все эти инструменты, 9 из 10 продуктов терпят неудачу.

На Хабре довольно много упоминаний о BDD. К сожалению, статьи, которые я читал, так и не дали мне ответа на вопрос «а зачем мне все это нужно?» Ответ пришел с неожиданной стороны. Когда я всерьез занялся вопросом автоматизации приемочного тестирования, мне под руку попалась книга Gojko Adzic (не уверен в транскрипции, поэтому не стал переводить имя автора) Specification By Example.
Читая ее, я не уставал удивляться: каждая новая глава описывала шишки, которые я набивал на своем личном опыте, и предлагала решения аналогичные или лучшие, чем те, к которым я приходил сам методом проб и ошибок.

Эта статья – первая в цикле «BDD для прагматиков». В ней описаны ключевые элементы наиболее эффективного, на мой взгляд, процесса разработки коммерческого ПО в современных условиях. Два продолжения будут посвящены работе со SpecFlow и автоматизации приемочного тестирования.

День добрый,
сим постом хочу предупредить русскоязычное сообщество о новой фишинг тенденции, семимильными шагами двигающейся по Европе. В настоящее время накрыло Германию. Думаю такими темпами очень быстро доберется до России и СНГ.

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

На такую уловку попадаются даже люди, серьезно относящиеся к безопасности своих данных, например проверяющие URL в браузерах перед оплатой PayPal и т.д. Это объясняется высоким уровнем доверия к информации, висящей например внутри крупного банка.

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

А сейчас, в период между Рождеством и Новым Годом, когда особенно обострена склонность к углублённой рефлексии, приходит понимание того, что, знай я некоторые «инсайдерские» подробности управленческой деятельности заранее – сделал бы совсем другой выбор лет эдак семь назад.

Вот поэтому и родился этот немного хаотичный и очень разнокалиберный список моментов, которые очень хотелось бы передать куда-то обратно, примерно в 2005 год – дайте знать, если кто-то вдруг уже научился это делать! А пока, может быть кто-то найдёт некоторые из перечисленных ниже пунктов не до конца очевидными, или даже полезными для себя; было бы приятно осознавать, что удалось помочь кому-то сделать более осознанный выбор профессии – или просто о чём-нибудь важном задуматься.

Мы решили, что лучшим способом рассказать о Дневник.ру будет не просто описать набор функций (о них можно прочитать у нас на сайте), а показать на примере того, как используется система в одной из школ – назовем ее «Гимназия №0».

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

В Гимназии №0, в 6-ом классе за одной партой сидят двое одноклассников и друзей:

Данный пост представляет собой выдержку «золотых правил» из примечательной книги Питера Гудлифа «Ремесло программиста».

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