Как стать автором
Обновить

Docker, часть вторая. Полуавтоматическая винтовка с самонаведением на ногу

Время прочтения 1 мин
Просмотры 22K
Разработка веб-сайтов *Анализ и проектирование систем *ООП *
Туториал
Пожалуйста, начинайте читать с начала серии: habrahabr.ru/post/267441

Как не надо использовать Docker.



Чтобы понимать эту статью надо знать базовые команды Dockerfile для создания изображений и принципы объектно-ориентированного дизайна.

Открываю документацию любого официального образа сервисного ПО — например, Nginx и нахожу раздел «How to use this image». Нам предлагают создать свой образ на базе официального, скопировав в него наши файлы, настроить мапинг порта в мир, и подмонтировать свою папку с конфигами.

FROM ...
COPY  . /usr/src/myapp
WORKDIR /usr/src/myapp

Да, нам предлагают унаследовать Model от View в одном звездном классе и заплатить за хранение на Docker Hub образов наших проприетарных приложений.
Читать дальше →
Всего голосов 29: ↑11 и ↓18 -7
Комментарии 48

Рецепты Docker: Monkey patch, часть третья

Время прочтения 5 мин
Просмотры 21K
Разработка веб-сайтов *PHP *Анализ и проектирование систем *
Пожалуйста, начинайте читать серию заметок с начала, здесь: habrahabr.ru/post/267441

Настройка локально



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

Беру образы Nginx и PHP 7.

~$ docker pull nginx
...
~$ docker pull php:7-fpm
Status: Downloaded newer image for php:7-fpm

Теперь у меня есть два чужих класса, которые надо связать вместе через внедрение зависимостей. Самый простой способ добавлять зависимости в чужой код, конечно же, monkeypatching! Сначала создаю контейнеры. Помню о второй сложности программирования — даю контейнерам вразумительные имена, они будут нужны, чтобы контейнеры могли взаимодействовать между собой.
Читать дальше →
Всего голосов 21: ↑8 и ↓13 -5
Комментарии 44

Dagger 2. Часть первая. Основы, создание графа зависимостей, Scopes

Время прочтения 10 мин
Просмотры 164K
Разработка веб-сайтов *Java *Разработка мобильных приложений *Разработка под Android *

Всем привет! В последнее время появилось много средств, библиотек, которые существенно облегчают написание кода под Android. Только успевай за всем следить и все пробовать. Одним из таких средств является библиотека Dagger 2.


В сети уже много различного материала, посвященного данной библиотеке. Но когда я только начинал ознакамливаться с Dagger 2, читал статьи, смотрел доклады, я во всем этом находил один общий недостаток — мне, как человеку, не работавшему со Springом и прочими подобными фреймворками/библиотеками, было довольно сложно понять, откуда берутся зависимости, как они "провайдятся" и что вообще там происходит. На слушателей/читателей обычно сразу "вываливается" большое количество кода с новыми аннотациями. И это как-то работало. В итоге, после доклада/статьи в голове все никак не могло сложиться в единую понятную картину.


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


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

Читать дальше →
Всего голосов 7: ↑7 и ↓0 +7
Комментарии 22

Dagger 2. Часть вторая. Custom scopes, Component dependencies, Subcomponents

Время прочтения 8 мин
Просмотры 111K
Разработка веб-сайтов *Java *Разработка мобильных приложений *Разработка под Android *

Всем привет!
Продолжаем наш цикл статей о Dagger 2. Если вы еще не ознакомились с первой частью, немедленно сделайте это :)
Большое спасибо за отзывы и комментарии по первой части.
В данной статье мы поговорим о custom scopes, о связывании компонентов через component dependencies и subcomponents. А также затронем такой немаловажный вопрос, как архитектура мобильного приложения, и как Dagger 2 помогает нам выстраивать более правильную, модульнонезависимую архитектуру.
Всем заинтересовавшихся прошу под кат!

Читать дальше →
Всего голосов 10: ↑10 и ↓0 +10
Комментарии 26

AndroidAudit. Ваше Android-приложение как место преступления

Время прочтения 11 мин
Просмотры 11K
Разработка мобильных приложений *Разработка под Android *Тестирование мобильных приложений *
Перевод


От переводчика: оценка процесса и результата разработки — достаточно субъективная вещь, если не используется какая-либо мера весов. Можно долго спорить: табы или пробелы, git или mercurial, maven или gradle, но такие споры все равно скатываются к вкусовщине и каким-то частным случаям. Другое дело — соблюдение однородности проекта, вот это уже вполне себе измеримая величина.
Плохая методология лучше её отсутствия.
Помимо общих вещей, найдутся и специфические, присуще только мобильной разработке, только под Android. Pedro Vicente Gómez Sánchez из Karumi в своей работе разобрал по косточкам основные технические области и задал меткие вопросы для правильной, объективной оценки разработки для платформы Android. Если появится задача: оценить чужой проект, то рекомендую воспользоваться его методологией. Я воспользовался этой методологией, как чек листом. На выходе получился вполне понятный не профессионалу документ, где напротив каждой категории — конкретная величина соответствия правильности от 0 до 1.

Читать дальше →
Всего голосов 8: ↑8 и ↓0 +8
Комментарии 2

Unit-тестирование в сложных приложениях

Время прочтения 5 мин
Просмотры 15K
Тестирование IT-систем *Программирование *Проектирование и рефакторинг *

Ни один разработчик в здравом уме и трезвой памяти при разработке сложных приложений (> 100K LOC, например) не станет отрицать необходимость использования тестирования вообще и модульного тестирования (unit tests) в частности. Это так же верно, как и то, что каждый разработчик постарается исключить бессмысленную работу из творческого процесса создания приложения. Где же та грань, которая отделяет необходимость от бессмысленности, если мы говорим о модульном тестировании в контексте сложных приложений? Пару своих соображений по этому поводу я изложил под катом.

Читать дальше →
Всего голосов 9: ↑9 и ↓0 +9
Комментарии 19

Страх и ненависть в отдельно взятом стартапе. Часть 1 — Cтрах

Время прочтения 4 мин
Просмотры 11K
IT-инфраструктура *DevOps *
Пришло время описать архитектуру и особенности эксплуатации одного приложения. И для себя, чтоб не забыть, и для других — попробовать показать, как делать не нужно. Все совпадения случайны, все персонажи выдуманы. Реальны только используемые технологии и описаные, гхм, архитектурные решения. Поехали.
Читать дальше →
Всего голосов 17: ↑16 и ↓1 +15
Комментарии 21

Страх и ненависть в отдельно взятом стартапе. Часть 2 — Ненависть

Время прочтения 4 мин
Просмотры 13K
Системное администрирование *DevOps *
Как сисадмин, я советую взять самый дорогой выделеный сервер без поддержки, RAID, большой storage для особых файлов, template для сайта поярче, и закупить AdWords по крайней мере на два дня.

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

Читать дальше →
Всего голосов 23: ↑23 и ↓0 +23
Комментарии 22

Манифест архитектурной боли

Время прочтения 3 мин
Просмотры 11K
Java *Разработка мобильных приложений *Разработка под Android *
Всем привет! Это будет необычная статья. Это будет статья-манифест! Манифест архитектурной боли! Хватит это терпеть, хватит это держать в себе. Возьми и скажи все, что думаешь об архитектуре. Все, что думаешь о «чистой архитектуре»! Все, все, все! От начинающих до неудержимых гиков.

Все под кат!

image
Читать дальше →
Всего голосов 50: ↑26 и ↓24 +2
Комментарии 18

Dagger 2. Часть третья. Новые грани возможного

Время прочтения 19 мин
Просмотры 58K
Java *Разработка мобильных приложений *Разработка под Android *

Всем привет! Наконец-то подоспела третья часть цикла статей о Dagger 2!


Перед дальнейшим прочтением настоятельно рекомендую ознакомиться с первой и второй частями.


Большое спасибо за отзывы и комментарии. Я очень рад, что мои статьи действительно помогают разработчикам окунуться в мир Даггера. Именно это и придает силы творить для вас дальше.
В третьей части мы с вами рассмотрим различные интересные и немаловажные фичи библиотеки, которые могут вам очень пригодиться.


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


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


Итак, хватит разглагольствовать, и вперед к новым знаниям!

Читать дальше →
Всего голосов 18: ↑17 и ↓1 +16
Комментарии 30

В разрезе: новостной агрегатор на Android с бэкендом. Разработка под Android: выработка архитектуры

Время прочтения 5 мин
Просмотры 5.8K
Программирование *Проектирование и рефакторинг *Разработка под Android *
Вводная часть (со ссылками на все статьи)

В водной статье я уже писал о том, что планируемым клиентом для проекта должен стать клиент Android: доступный большой аудитории, лёгкий, функциональный, красивый, быстрый (не приложение, а мечта!). Если с основаниями выбора платформы всё понятно, то с тем как реализовывать на базе неё все перечисленные требования – ясно было далеко не всё.

Ранее разработкой под Android не занимался поэтому достаточно ценными источниками информации для меня являлись:


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

  • Логика работы с объектами Android (Activity, Preferences, TextView ….) перемешивалась с бизнес-логикой;
  • Объекты хранения фигурировали в коде построения интерфейса;
  • Модульное тестирование превращалось в ад из-за необходимости работы с родными объектами Android и их подмены экземплярами Robolectric;
  • Проверка асинхронного кода была возможна только на устройстве или эмуляторе (по принципу: «запустил-проверил-повторил»).
Читать дальше →
Всего голосов 5: ↑5 и ↓0 +5
Комментарии 2

Never Fail Twice, или как построить мониторинговую систему с нуля

Время прочтения 10 мин
Просмотры 12K
Python *Программирование *Анализ и проектирование систем *Алгоритмы *DevOps *
У нас было 2 виртуальные машины, 75 сайтов, десятки тысяч машин для мониторинга, тысячи метрик, две базы данных и одна очередь ActiveMQ, Python и целое множество библиотек всех сортов и расцветок, pandas, а также numpy, dash, flask, SQL Alchemy. Не то чтобы это был необходимый запас для системы, но если начал собирать компоненты, становится трудно остановиться. Единственное, что вызывало у меня опасение — это JavaScript. Ничто в мире не бывает более беспомощным, безответственным и порочным, чем JS зомби. Я знал, что рано или поздно мы перейдем и на эту дрянь.

image
Читать дальше →
Всего голосов 17: ↑15 и ↓2 +13
Комментарии 9

Многомодульность в Android с точки зрения архитектуры. От А до Я

Время прочтения 20 мин
Просмотры 56K
Блог компании «Лаборатория Касперского» Java *Разработка мобильных приложений *Разработка под Android *
Всем привет!

Не так давно мы с вами осознали, что мобильное приложение — это не просто тонкий клиент, а это действительно большое количество самой разной логики, которое нуждается в упорядочивании. Именно поэтому мы прониклись идеями Clean architecture, прочувствовали, что такое DI, научились использовать Dagger 2, и теперь с закрытыми глазами способны разбить любую фичу на слои.

Но мир не стоит на месте, и с решением старых проблем приходят новые. И имя этой новой проблемы — мономодульность. Обычно об этой проблеме узнаешь, когда время сборки улетает в космос. Именно так и начинаются многие доклады про переход на многомодульность (раз, два).
Но почему-то все при этом как-то забывают, что мономодульность сильно бьет не только по времени сборки, но и по вашей архитектуре. Вот ответьте на вопросы. На сколько у вас AppComponent большой? Не встречаете ли вы периодически в коде, что фича А зачем-то дергает репозиторий фичи Б, хотя вроде такого быть не должно, ну или оно должно быть как-то более верхнеуровнево? Вообще у фичи есть какой-то контракт? А как вы организовываете общение между фичами? Есть какие-то правила?
Вы чувствуете, что мы решили проблему со слоями, то есть вертикально все вроде хорошо, но вот горизонтально что-то идет не так? И просто разбиением на пакеты и контролем на ревью не решить проблему.

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

В своей статье я хочу вам рассказать, как дошел до многомодульности именно с архитектурной точки зрения. Какие проблемы меня беспокоили, и как я их старался поэтапно решать. А в конце вас ждет алгоритм перехода с мономодульности на многомодульность без слез и боли.
Читать дальше →
Всего голосов 25: ↑24 и ↓1 +23
Комментарии 18

Generics + Spring: Да пребудет с вами сила

Время прочтения 5 мин
Просмотры 13K
Программирование *Java *

Однажды в одном далёком, далёком банке ...


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

Эпизод 1:


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

Проблему с общими полями я решил просто — наследованием. Таким образом у меня появились классы:

public class Transfer {
    private TransferType transferType;
    ...
}
    
public enum TransferType {
      INTERNAL, SWIFT, ...;
}
    
public class InternalTransfer extends Transfer {
    ...
}
    
public class BaseRequest {
    ...
}
    
public class InternalRequest extends BaseRequest {
    ...
}    

...

Эпизод 2:


Дальше стояла проблема с контроллерами — у них у всех должны были быть одинаковые методы — checkTransfer, approveTransfer и тд. Вот тут то в первый, но не в последний раз мне пригодились дженерики: я сделал общий контроллер с нужными методами, и унаследовал от него остальные:
Читать дальше →
Всего голосов 12: ↑12 и ↓0 +12
Комментарии 5

Middleware и возможности Pipeline в Laravel

Время прочтения 7 мин
Просмотры 20K
PHP *Laravel *
Туториал
Из песочницы


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

И сегодня речь пойдет об одном из таких инструментов, а точнее о его использовании и реализации со стороны программиста. Отсутствие полноценной документации, а также отсутствие русскоязычных статей и очень малое количество статей иностранных — подтолкнуло меня к решению раскрыть некую завесу тайны об этой интересной возможности фреймворка и выбору этой темы в качестве моей первой статьи на Хабре.
Читать дальше →
Всего голосов 30: ↑30 и ↓0 +30
Комментарии 9

Микросервисы на Go с помощью Go kit: Введение

Время прочтения 12 мин
Просмотры 46K
Go *Микросервисы *
Перевод

В этой статье я опишу использование Go kit, набора инструментов и библиотек для создания микросервисов на Go. Эта статья — введение в Go kit. Первая часть в моем блоге, исходный код примеров доступен здесь.

Читать дальше →
Всего голосов 20: ↑19 и ↓1 +18
Комментарии 7

Navigation in Multi-Module Projects

Время прочтения 10 мин
Просмотры 8.3K
Разработка мобильных приложений *Разработка под Android *Kotlin *
Из песочницы


Navigation in developing Android apps is quite important and you should think twice what library suits (or your own solution) most and how it will be convenient to use when the app becomes bigger. Also, it might be good to think about how easy it will be to change your implementation to another one.
Read more →
Всего голосов 13: ↑13 и ↓0 +13
Комментарии 1

Kaspersky Mobile Talks #1. Многомодульность

Время прочтения 8 мин
Просмотры 8.4K
Блог компании «Лаборатория Касперского» Разработка мобильных приложений *Разработка под Android *

В конце февраля мы запустили новый формат встреч Android-разработчиков Kaspersky Mobile Talks. Основное отличие от обычных митапов — здесь вместо сотни слушателей и красивых презентаций на несколько различных тем собрались «бывалые» разработчики, чтобы обсудить всего лишь одну тему: как они реализуют многомодульность в своих приложениях, с какими проблемами сталкиваются, и как их решают.


Читать дальше →
Всего голосов 18: ↑16 и ↓2 +14
Комментарии 0

Код живой и мёртвый. Часть первая. Объекты

Время прочтения 7 мин
Просмотры 14K
Совершенный код *.NET *Проектирование и рефакторинг *C# *ООП *

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


И вместе с этим мы видим повсеместную эпидемию менеджеров, хелперов, сервисов, контроллеров, селекторов, адаптеров, геттеров, сеттеров и другой нечисти: всё это мёртвый код. Он сковывает и загромождает.


Бороться предлагаю вот как: нужно представлять программы как текст на естественном языке и оценивать их соответственно. Как это и что получается — в статье.

Читать дальше →
Всего голосов 34: ↑28 и ↓6 +22
Комментарии 55

Код живой и мёртвый. Часть вторая. Действия и свойства

Время прочтения 6 мин
Просмотры 5.7K
Программирование *Совершенный код *Проектирование и рефакторинг *C# *ООП *

В прошлый раз я писал о том, что имена объектов имеют большое значение, и что подбирать их нужно кропотливо и со вниманием к деталям. Плохое имя отпугивает и не даёт вникнуть в суть происходящего. Но что это за суть?


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


Об этом — в статье.

Читать дальше →
Всего голосов 18: ↑17 и ↓1 +16
Комментарии 62
1