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

Автор: Вячеслав Михайлов

Монолитные приложения и их проблемы

Все прекрасно знают, что такое монолитное приложение: все мы делали такие двух- или трехслойные приложения с классической архитектурой:

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

Так или иначе, по мере роста и развития приложения, вы сталкиваетесь с проблемами монолитных архитектур:

• сложность системы постоянно растет;
• поддерживать ее все сложнее и сложнее;
• разобраться в ней трудно — особенно если система переходила из поколения в поколение, логика забывалась, люди уходили и приходили, а комментариев и тестов нет);
• много ошибок;
• мало тестов — монолит не разобрать и не протестировать, поэтому обычно есть только UI-тесты, поддержка которых обычно занимает много времени;
• дорого вносить изменения;
• застревание на технологиях (например, я работал в компании, где с 2003 г. технологии до сих пор не изменились).

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

В предыдущей части статьи был разобран общий принцип работы системы: мы увидели, что двумя основными её блоками являются интерполятор и нумератор. Мы построили схему взаимодействия, а также полностью обсудили реализацию интерполятора. В этой части мы разберём реализацию нумератора: обратимой функции, переводящей набор значений ключевых полей в натуральное число (BigInteger) таким образом, что набор меньше набора с точки зрения СУБД тогда и только тогда, когда . Говоря проще — научимся интерполировать наборы значений и, что самое интересное, строки:

Предлагаю вашему вниманию перевод статьи "Replace Throw With Notification" Мартина Фаулера. Примеры адаптированы под .NET.

Если мы валидируем данные, обычно мы не должны использовать исключения, чтобы известить о валидационных ошибках. Здесь я опишу как отрефакторить такой код с использованием паттерна «Уведомление» («Notification»).



Недавно я смотрел на код, который делал базовую валидацию входящих JSON сообщений. Это выглядело примерно так…

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

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



Все дело в том, что разработка ПО — это не просто алгоритмы или языки.

КДПВ

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

У вас возникает вопрос: какие качества программного обеспечения приводят разработчика к успеху или к неудаче? Как я могу улучшить свой софт и помочь бо́льшему количеству людей стать успешным? Я могу ясно сформулировать некоторые основные принципы или полагаюсь на интуицию в зависимости от конкретного случая? (Рождение и воплощение одной мысли это два совершенно разных действия).

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

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

Мартовский вечер,
Расцветает сакура,
Быть Rambler.iOS.

Пришла весна, и мы, команда iOS-разработки холдинга Rambler&Co, с удовольствием анонсируем следующую конференцию — Rambler.iOS 6. Конференция состоится 30 марта в нашем офисе на Даниловской мануфактуре.

Наше путешествие от стандартных Activity и AsyncTask'ов к современной MVP архитектуре с применением RxJava.

Код проекта должен быть разделён на независимые модули, работающие друг с другом как хорошо смазанный механизм — фото Честера Альвареза.

Экосистема средств разработки под Android развивается очень быстро. Каждую неделю кто-то создаёт новые инструменты, обновляет существующие библиотеки, пишет новые статьи, или выступает с докладами. Если вы уедете в отпуск на месяц, то к моменту вашего возвращения уже будет опубликована свежая версия Support Library и/или Google Play Services.

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

Таблица (грид) с вертикальной полосой прокрутки — наиболее распространённый элемент пользовательского интерфейса для работы с данными реляционной БД. Однако известны сложности, с которыми приходится сталкиваться, когда таблица содержит так много записей, что тактика их полной вычитки и сохранения в оперативной памяти становится неразумной.

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



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

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

Здрасте! Наверняка многие знают, что такое CMS Битрикс, что она из себя представляет и какие «замечательные» код и архитектурные решения представляют его разработчики. В данном посте я хотел бы предложить новое видение на разработку компонентов и модулей системы.

От переводчика: — я давненько интересуюсь тем, как сделать код Android-приложений чище, и это, наверное, первая статья, после которой у меня не возникло мыслей: "Зачем вот это вот все?" и "Он вообще пробовал когда-то это использовать в жизни?" Поэтому решил перевести, может, еще кому-то будет полезно.

Написать Hello World всегда легко. Код выглядит просто и прямолинейно, и кажется, что SDK очень адаптирована под ваши нужды. Но если у вас есть опыт написания более сложных Android-приложений, вы знаете, что с рабочим кодом все не так. Можно провести часы за попыткой понять, почему ваша корзина покупок не обновляется после изменения ориентации телефона, если недоступен WiFi. Вы предполагаете, что решением проблемы, возможно, будет добавить ещё один if в 457-строчном методе onCreate() вашей активити — где-то между тем кодом, который исправляет падение на самсунгах с Android 4.1 на борту, и тем, который показывает купон на 5$ в день рождения пользователя. Что ж, есть способ получше.

Мы в Remind (прим. пер. — название компании, где работает автор) выкатываем новые функции каждые две недели, и для того чтобы поддерживать эту скорость и высокое качество продукта, нужен способ сохранять код простым, поддерживаемым, разделённым (прим. пер. — "decoupled", в смысле слабой связанности) и тестируемым. Использование архитектурного паттерна MVP позволяет нам делать это и сосредоточиваться на самой значимой части нашего кода — нашей бизнес-логике.

Введение

Статья написана с точки зрения программиста из техподдержки ERP системы.

Выполняя очередное тестовое задание, по очередной вакансии, мне в голову пришла очередная гениальная идея.
Почему бы не отдать пользователю редактирование формул для вычисления колонок отчёта? Получиться тот же самый Excel к которому все привыкли, только синтаксис — SQL.

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

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

Что это?

Библиотека TOM.js даёт возможность облегчить такие задачи как:

• загрузка/подгрузка скриптов/стилей с зависимостями
• создание/наследование классов
• перехват функций в пределах приложения

Шаблоны проектирования! Впервые я узнал о них на курсе Software Design, когда учился в магистратуре Академического университета. Мы писали различные программы на Java с использованием шаблонов. С тех пор это словосочетание ассоциируется у меня с чем-то таким ООПшным. Однако, разбираясь с языком Agda, я наткнулся на статью The Power Of Pi, которая рассказывает про шаблоны проектирования в языках с зависимыми типами!

В этом посте я хочу рассказать об одном из этих шаблонов, который называется View. С его помощью можно реализовывать пользовательские правила pattern matching'a. Если вам интересно, что это за шаблон, что такое пользовательский pattern matching, каковы особенности pattern matching'а в языках с зависимыми типами, и вы знакомы с каким-нибудь функциональным языком программирования со статической типизацией (Haskell, Scala, Ocaml, F#) — добро пожаловать под кат!

Автор: Вячеслав Михайлов, Solutions Architect.

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

Часть 1. Теория

Итак, как мы все знаем, API — application programming interface (интерфейс программирования приложений), набор правил и механизмов, с помощью которых одно приложение или компонент взаимодействует с другими

Почему хороший API — это важно?

• Простота использования и поддержки. Хороший API просто использовать и поддерживать.
• Хорошая конверсия в среде разработчиков. Если всем нравится ваш API, к вам приходят новые клиенты и пользователи.
• Выше популярность вашего сервиса. Чем больше пользователей API, тем выше популярность вашего сервиса.
• Лучше изоляция компонентов. Чем лучше структура API, тем лучше изоляция компонентов.
• Хорошее впечатление о продукте. API — это как бы UI разработчиков; это то, на что разработчики обращают внимание в первую очередь при встрече с продуктом. Если API кривой, вы как технический эксперт не будете рекомендовать компаниям использовать такой продукт, приобретая что-то стороннее.

Теперь посмотрим, какие бывают виды API.

Виды API по способу реализации:

• Web service APIs
  
  • XML-RPC and JSON-RPC
  • SOAP
  • REST
  
  
• WebSockets APIs
• Library-based APIs
  
  • Java Script
  
  
• Class-based APIs
  
  • C# API
  • Java
  
  

Виды API по категориям применения:

• OS function and routines
  
  • Access to file system
  • Access to user interface
  
  
• Object remoting APIs
  
  • CORBA
  • .Net remoting
  
  
• Hardware APIs
  
  • Video acceleration (OpenCL…)
  • Hard disk drives
  • PCI bus
  • …
  
  

Недавно я выступал на конференции Droidcon в Париже с докладом (оригинал на французском), в котором рассматривал проблемы, возникшие у нас в Square при работе с фрагментами и возможности полного отказа от фрагментов.

В 2011-м мы решили использовать фрагменты по следующим причинам:

• Тогда мы ещё не поддерживали планшеты, но знали, что когда-нибудь будем. Фрагменты помогают создавать адаптивный пользовательский интерфейс, и потому казались хорошим выбором.
• Фрагменты являются контроллерами представлений, они содержат куски бизнес-логики, которые могут быть протестированы.
• API фрагментов предоставляет возможность работы с backstack'ом (в общих чертах это выглядит так же, как и работа со стэком Activity, но при этом вы остаётесь в рамках одной Activity).
• Так как фрагменты построены на обычных представлениях (views), а представления могут быть анимированы средствами Android-фреймворка, то фрагменты могли в теории дать нам возможность использовать более интересные переходы между экранами.
• Google рекомендовал фрагменты к использованию, а мы хотели сделать наш код как можно более стандартным.

С 2011-го года много воды утекло, и мы нашли варианты получше.

Введение

Кнопки «Undo» и «Redo», позволяющие отменить и вернуть обратно любые пользовательские действия, а также посмотреть в списке перечень всех выполненных действий, являются стандартом де-факто для таких приложений, как текстовые процессоры и среды разработки, редакторы графики и САПР, системы редактирования и монтажа звука и видео. Они настолько привычны для пользователя, что последний воспринимает их наличие как данность, всего лишь одну функциональную возможность наряду с десятками других. Но с точки зрения разработчика требование к наличию undo является одним из факторов, влияющих на всю архитектуру проекта, определяемую на самых ранних стадиях проекта разработки.



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

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

Что такое MVP

MVP – это способ разделения ответственности в коде приложения. Model предоставляет данные для Presenter. View выполняет две функции: реагирует на команды от пользователя(или от элементов UI), передавая эти события в Presenter и изменяет gui по требованию Presenter. Presenter выступает как связующее звено между View и Model. Presenter получает события из View, обрабатывает их(используя или не используя Model), и командует View о том, как она должна себя изменить.

У такого подхода к разделению ответственности есть ряд плюсов:

1. Сильно упрощается написание тестов к коду
2. Легко менять какую-то часть, не ломая при этом другую
3. Код разбивается на мелкие кусочки, за счёт чего он становится более понятным и читабельным

В то же время, конечно, есть и минусы:

1. Кода становится больше
2. К этому подходу нужно привыкать
3. На данный момент не сильно распространённый(но известный) подход, поэтому приходится всем рассказывать о нём

Дорогой разработчик!

Я давно хочу с тобой поговорить, но слова не всегда даются легко. Мы отлично проводили время вместе. Я всё ещё помню первый раз, когда я предупредил тебя о мелкой ошибке в коде, и как же ты был рад тому, что я есть в твоей жизни! Ты это помнишь? Ещё я помню, как ты впервые рефакторил меня, чтобы сделать меня более эффективным, и как хорошо написанным я чувствовал себя после этого… ах, замечательные времена!

Я обязан тебе всем, я знаю. И я благодарен за это. Меня бы не было, если бы не ты. Ты подумал, что я нужен, поэтому ты создал меня, и с того момента я служу тебе, радуясь этому, поскольку ты наделил меня смыслом. Я хочу ловить баги для тебя. Я хочу вселять в тебя уверенность в том, что вещи продолжат работать после твоих изменений. Я хочу сделать твою жизнь проще, и ты знаешь, что я могу сделать все эти вещи, — я уверен, что ты знаешь.

Но потом я стал необъяснимо падать время от времени, безо всякой видимой причины. Что-то немного сломалось во мне. Я продолжал функционировать почти нормально, но ничего не мог поделать с тем, что иногда становился причиной красных сборок, это было просто не в моей власти. Я стал… нестабильным. Моя нестабильность расстроила тебя, и я не злюсь на тебя за это, поскольку меня она тоже расстроила. Я перестал быть надёжным. Я утратил свой смысл. Я должен сказать, что сейчас мне горько вспоминается твоя реакция после нескольких недель моей нестабильности: вместо того, чтобы вложить чуточку любви и потратить пару часов на то, чтобы исправить меня и привести в хорошее состояние, ты пометил меня как @ignore и бросил в огромной пустынной куче кода.