Android Studio, Gradle, соц. сети

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

Простое, но странное в Android

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

Bootstrap + jQuery UI Autocomplete

Подключить jQuery UI Autocomplete к сайту на Bootstrap довольно просто, единственное - нужно немного допилить стили. Всем страждущим в помощь:

Про ClojureSript, пыщ-пыщ и в продакшн

Нарезка самых сочных моментов из выступления Александра Соловьёва на JavaScript Frameworks Day 2013. Доклад был про ClojureScript, полная версия - тут

PhoneGap step by step: установка и настройка

Небольшое руководство по установке и настройке PhoneGap на Windows-машине.
Возможные проблемы и способы решения в конце руководства. 

Tortoise svn 1.8: bugged edition

Эх, черепаха, что ж ты делаешь? Адпейт до последней стабильной версии Tortoise SVN 1.8, который просит для работы Visual SVN, несёт с собой необходимость переконвертировать working directory в новый формат. И старые версии черепашки не понимают этот формат (что вполне ожидаемо). 

Но при попытке апдейта кода из репозитория сюрприз!
The PROPFIND response did not include the requested properties

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

Мораль этого всего такова: не стоит спешить опробовать чужие баги на своей шкуре. С tortoise svn это случалось уже не раз, и, видимо, не раз повторится. Любите своих пользователей, убирайте бажные релизы с серверов или максимально быстро выпускайте баг-фиксы, параллельно предупреждая пользователей об опасности. 

ProblemFactory

Кодинг на улице

Ведь так оно и есть.

Перед...

Перед началом очередного проекта
Перед добавлением нового функционала
Перед улучшением работающего кода

TDDigest e05

Интереснейший пост от компании Badoo об "Оптимальной параллелизации юнит-тество или 17000 тестов за 4 минуты" #ru

BDD in Action: Часть 1, Часть 2
Let your tests tell you when your code design sucks.
Why Not To Want 100% Code Coverage

Tips and tricks для  более эффективного использования phpUnit в слайдах PHPUnit best practicies. А так же, чем хорош phpUnit для создания mock-объектов - хорошая статья на Хабре. И, закрывая тему phpUnit, Parallel testing for phpUnit with ParaTest

TDD Javascript with Jasmine #video  #en

Статья Building the right software…right, It’s easy…RIGHT? с разъяснением разницы, что значит делать правильно и делать правильное. Путаница возникает, в основном, из-за использоания ATDD и BDD и TDD... Слишком много букв D, всё driven, только в какую сторону? Автор предлагает следующую структуру: сначала используется BDD - для определения целей, за ним - ATDD - для реализации целей, и потом TDD - для качественной реализации.
И небольшое видео, в котором объяняется разница между BDD и TDD:

Все знают мантру TDD "Red-Green-Refactoring", но как мы определяем, что рефакторинг нужен? И как найти золотую середину между минимизацией времени, затрачиваемом на разработку, и качеством кода, который придеся кому-то сопровождать в будущем?  Об этом речь в видео (а заодно и слайдах) Code Smells: Your Refactoring Cheat Codes #en #video #tdd #refactoring

Правильный подход к вопросу о unit-тестировании кода на stackoverflow. #en #php

О синергии тестируемости кода и дизайна приложения #video #en

Обсуждение трёх подходов к mobile testing:

TDDigest e04

В сегодняшней подборке материалов из мира TDD много видео интересных выступлений и интервью.
Видео с выступления #Сергея Теплякова на msswit "Тестируемая архитектура: моки, стабы, рефакторинг" #video #ru #mock #design #msswit

"TDD I learned..." - автор рассказывает о своих неудачных попытках писать тесты и полном непонимании бенефитов TDD до тех пор, пока не натолкнулся на мастер-класс Roy Osherove по TDD. Из видео, которое идет более 9 часов, автор вынес для себя много полезного, понял разницу между интеграционными тестами и юнит тестами, и впечатлился AAA-подходом (Arrange, Act, Assert):

This approach, by eliminating assert code intermixed with code that sets up or acts upon your objects, reduces smelly tests by separating what is being tested from all the other stuff.

Такой подход разделяет проверку (assert) результата, инициализацию объектов (arrange) и действия над ними (act), отделяя то, что нужно протестировать, от всего остального, тем самым устраняя дурной "запашок-с" тестов.

#en #tdd

Интересное интервью со Стивом Фрименом и Нэтом Прайсом, авторами книги "Growing Object-Oriented Software, Guided by Tests"

How do you start a new project with TDD? -  своеобразный подход к настройке среды для нового проекта. #en
BDD and Acceptance Testing with RSpec & Capybara #en #video #ruby #bdd #rspec
Drupal unit testing #en #drupal #php
Беседа о unit-тестировании в php #en #php #unit-testing
Юнит-тестирование в CakePhp #en #php #unit-testing #video
JUnit / TestNG Testing Spring Security With Spring MVC Test Framework

Инструменты

Mockery - ещё один mock-фреймворк для unit-тестов
atoum.js - стильный, модный, молодёжный ;) фреймфорк для тестирования PHP5.3+ теперь и для js
Swaks - швейцарский нож для тестирования SMTP
dotCover - тест-ранер, а так же инструмент для  сбора аналитики о степени покрытия кода тестами для VS от JetBrains (правда, платный)

TDDigest e03

Для начала разберёмся, как писать тестируемый код на javascript, и поговорим о том, как тестировать полученный код с помощью QUnit, а так же как наслаждаться процессом тестирования асинхронного javascript с помощью Mocha #javascript #en #mocha

Туториал о том, как писать тестируемый и поддерживаемый код на php, чего избегать в коде, а что, наоборот, является правильным подходом. Ещё серия туториалов, детально раскрывающих процесс юнит-тестирования с PHPUnit. Рассматриваются такие темы, как написание полезного теста (!), моки, стабы, dependency injection, тестирование закрытых методов класса (если уж очень нужно), перегруженные конструкторы и почему 100% покрытие кода не так уж и важно. #en #php #phpunit

TDDigest e02

Открывает второй выпуск tddigest немного филосовский пост "10 Правил Дзен-Программиста" от Christian Grobmeier #en #zen

Размышления на тему "Design for tests vs Design for API" #en #tdd #ruby

Очередные tips & tricks от php-девелоперов. В прошлый раз нам показывали, как тестить защищённые методы класса, а в этот раз говорят о том, как надо мокать singleton с помощью PHPUnit. Забавно, ведь даже на самом php.net красным написано: Ахтунг! Берегись синглтона! (шутки в сторону) А теперь серьёзно, когда может пригодиться такой подход? Я вижу один случай - есть база legacy кода, которую нужно поддерживать. Рефакторить код или вносить изменения без тестов -  смело, но глупо. Поэтому приходится иногда заниматься таким: мокать синглоны или чего ещё хуже выдумывать. #php #phpunit #antipattern

10 особенностей CoffeeScript, о которых вы могли не знать

Немного вольный перевод статьи "10 CoffeeScript Features You Might Not Know" by Jaco Pretorius.

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

Сводка с фронтов от инфицированных тестами e01

Открывает первую сводку с фронтов удараников TDD хвалебная статья-ода "Not Using Test-First? You're Doing it Wrong." Автор не просто рассказывает, почему TDD - это круто, а пытается объяснить, как и чем улучшает test-first подход процесс разработки. #en #tdd
Продолжая тему полезности TDD "Why Testing Makes a Project Successful and You Can’t Afford to Deny It". Автор развивает мысль о полезности тестирования, эпично приводя статистику расхода времени и денег на поиск и фикс багов:

According to prweb.com, recent Cambridge University research found that, on average, software developers spend 50% of their programming time finding and fixing bugs and estimate that this costs the global economy $312 billion per year.

Да уж, не кисло. Не будь частью этой статистики, пиши теты! #en

love via soap II: php + c#

Часть 1, в которой рассказывалось, зачем это всё нужно, и как несложно реализуется взаимодействие  php-клиента с asmx-сервисом.

В этой части мы будем писать SOAP-сервис на php, а клиентскую часть - на C#.Так что пристегнись, это php!

Микромир ORM на примере Massive

В мире больших и тяжеловесных ORM-решений, таких как NHibernate и Entity Framework, вполне предсказуемым стало появление течения микро-ORM: легковесных прослоек между БД и объектами приложения. Чем хороши microORM? Прежде всего, скоростью выполнения запросов: она сопоставима со скоростью чистых запросов через SqlDataReader. Потом - микро размерами: например, Massive - это всего лишь один подключаемый файл на 673 строки кода, в отличие от NHibernate или EF, которые тянут за собой целую dll-ку на несколько сот килобайт.  Наиболее известные из micro ORM:

1) Dapper, разработанный и активно использующийся в StackOverflow и StackExchange
2) Massive, разработанный Rob Conery, пример использования - HanselMinutes
3) PetaPOCO

Massive - это лучше, чем шоколад

Основа Massive - это dynamic-типы, появившиеся в .NET 4.0. Чтобы понять, что такое Massive, как и зачем он появился на свет, посмотриет видео  "Kill your ORM" с выступления Роба Конери на NDC 2011. А чтобы понять, насколько Massive лучше шоколада,  давайте напишем небольшое тестовое приложение, выводящее план счетов из БД в сгруппированом виде.

3 js-фреймворка на личном опыте

Разрабатывая веб-приложение (не путать с веб-сайтом с интерактивным UI) на jQuery, Zepto или другом UI-ном фреймворке, довольно быстро приходишь к изобретению MV*-велосипеда, сначала  отделяя данные от UI-части приложения, а потом назначая ответственного за взаимодействием между ними. Резонный вопрос: а какие существуют готовые решения, облегчающие взаимодействие UI, данных и логики, поверх jQuery (Zepto)? И как ответ недавно мне попалась статья "A Collection Of Javascript MVC Frameworks That You Should Know About". Знаете, сколько там фреймворков? Больше 30! Как же сделать правильный выбор? Выбор фреймворка - это серьезное решение, от которого не последним образом зависит будущее проекта. На решение каких проблем большим образом ориентирован фреймворк? Какой из MV* подходов используется во фреймворке (и стоит ли на этом заморачиваться)? Сильно ли тяжеловесен фреймворк? Сколько дополнительных библиотек он тянет за собой? Насколько быстро и легко разобраться с устройством фреймворка? Насколько хороша документация? Есть ли дружное сообщество вокруг библиотеки? Как не ошибиться, ведь все фреймворки похожи друг на друга, и каждый обещает сделать всю работу за меня? Да никак. Есть лишь несколько подсказок и советов от умудрённых опытом людей и сделанные на основе собственного опыта выводы.

Философия AMD, RequireJs и модульная разработка веб-приложений на JavaScript

Разделяй и влавствуй - подход на все времена. Концепция модульного программирования не нова, и хорошо себя зарекомендовала. В мире разработки web-приложений на JavaScript существует подход Asynchronous Module Definition или AMD, который

specifies a mechanism for defining modules such that the module and its dependencies can be asynchronously loaded [1]

т.е. по сути определяет API, следуя которому можно реализовать асинхронную загрузку самих модулей и их зависимостей. Следуя этому подходу, непроизвольно создаешь более элегантные решения, но это всего лишь бонусный побочный эффект. Главное - уменьшается хаос js-кода, сложность разработки и поддержки приложения. Каждый модуль явно указывает свои зависимости и получает только их, работая изолированно, что означает минимум мусора глобальной области видимости.
Всё, что нужно, чтобы начать использовать AMD подход в проекте, - это загрузчик, который знает, что такое AMD-модуль, и умеет подгружать зависимости.  Итак,

Keypress event в Knockout.js

Столкнулась с проблемой в knockout.js: в текстовом нужно было отследить нажание кнопки Enter. Делов-то: привязываем к событию keypress нужный метод, и в нём уже смотрим, какая клавиша была нажата:
//html
<div>
    <input type="text" data-bind="value: someValue, event : { keypress = function(data, event) { handleKeyPress(data, event) } }" />
    <span data-bind="text: someValue"></span>
</div>

//view model
var ViewModel = function() {
    var self = this;
    self.someValue = ko.observable('');

    self.handleKeyPress = function(data, event)
    {
           if (event.keyCode == 13)
           {
               //сделать что-нибудь полезное
           }
    }
}   
ko.applyBindings(new ViewModel()); 
Но не тут-то было! После таких манипуляций текстовое поле перестало реагировать на нажатия всех клавиш, кроме enter. Помогло создание своего специализированного binding-а:
ko.bindingHandlers.enterKey = {
    init: function(element, valueAccessor, allBindings, vm) {
        ko.utils.registerEventHandler(element, "keyup", function(event) {
            if (event.keyCode === 13) {
                ko.utils.triggerEvent(element, "change");
//set "this" to the data and also pass it as first arg, in case function has "this" bound
                 valueAccessor().call(vm, vm);
            }
          
            return true;
        });
    }        
}; 
В html это отразится привязыванием на созданный байндинг нужного метода:
<div>
    <input type="text" data-bind="value: someValue, enterKey: doSomething } }" />
    <span data-bind="text: someValue"></span>
</div>
Спасибо stackoverflow

Плохой программист

Наверное, многим знакома ситуация, когда, взглянув на чей-то код, думаешь "$%#... как можно так писать?!" Тут даже рефакторить бесполезно! Выкинуть бы да переписать с нуля! А бывало ли так, что вы сами оказывались по ту сторону баррикад? Что кто-то смотрел на ваш код, и в глазах ревизора читался ужас :)?

А как вы сами относитесь к коду, написанному вами же, полгода, год, два года назад? Кажется ли применённый подход и найденное решение таким же правильным? Или как-то так?

Лично я считаю такую реакцию вполне нормальной и, даже, правильной.

Полгода (не говоря уже о том, что целый год), - это большой отрезок времени. Это целых 182 дня = 4368 часа, из которых 2912 часа человек бодрствует (при расчете, что на сон уходит 8 часов). Достаточно ли 2912 часов, чтобы узнать хоть что-нибудь новое и полезное для себя?

За полгода могут измениться взгляды на всё, ведь даже новое хобби или прочитанная книга (статья)  - это способ открыть для себя что-то новое. Знакомство с новой технологией или изучение другого языка программирования - это способ научиться мыслить иначе. Хотя...

Программист на Фортране может написать программу на Фортране на любом языке программирования.
Ed Post, 1983

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

It is possible that you are a bad programmer. You'll never know until someone better sees it.
(c) Scott Hanselman

И пусть этим someone better будете вы сами :)

Компиляция CoffeeScript в JavaScript используя Sublime Text 2

CoffeeScript - рафинированный JavaScript, который хочется писать ещё и ещё. Цель этой заметки рассмотреть, как писать и компилировать код на CoffeeScript в js, используя Sublime Text 2.

Весь процес можно разбить на два этапа:
1. Подготовительный этап - установка компилятора CoffeeScript
2. Установка плагина CoffeeScript под Sublime Text 2
И так, приступим.