Покончим с устаревшим подходом к контенту

На протяжении всей истории интернета мы работали с контентом двумя способами:

1. Создавали «один шаблон на все случаи жизни»
2. Создавали для каждого случая свой уникальный шаблон

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

Доброго времени суток всем хабражителям. Меня зовут Илья Шакитько и я работаю в LeaseWeb, в команде, работающей над облачными сервисами. Решая очередную задачу, связанную с исследованием той или области, мы стараемся поделиться полученными знаниями или мыслями с сообществом. Не так давно мы проводили DevOps встречу в нашем офисе, где одним из выступающих был мой коллега, Мауритс ван дер Скхи, который рассказывал об API First архитектуре. Немногим ранее в нашем блоге он опубликовал статью, переводом которой я хотел бы поделиться с вами.

Введение

API First архитектура это архитектура, для которой API пользователь является основным пользователем приложения. Это означает, что этот API должен иметь наивысший приоритет, а не быть еще одним представлением (view) в парадигме MVC. Основное различие состоит в том, что API First требует наличия полного, адаптивного и хорошо документированного API. Это особенно важно в таргетировании: на мобильных платформах (приложения используют API), у реселлеров (слой представления использует API) и в многопродуктных средах с высокой интеграцией, но малой связанностью.

После того, как компания Motorola была приобретена поисковым гигантом Google в 2011, новый владелец не оказывал никакого особо влияния на выпуск смартфонов. Но вскоре компания невероятно быстро и стремительно претерпела изменения. Первыми и весьма успешными продуктами обновленной Motorola стали Moto X и линейка DROID для оператора связи Verizon. Далее компания заявила, что собирается начать завоевывать рынки, которые ещё полностью не сформированы. Первым ходом в этом направлении стал выпуск бюджетного смартфона Moto G.



И если Nexus 5 это скорее смартфон для гиков и поклонников данной линейки, а Moto X в основном для людей, которые не могут устоять перед созданием своего собственно дизайна, то Мото G для тех, кто хочет функциональное устройство по разумной цене.

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

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



О процессе разработки сервиса и расскажу.

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

И вот одному менеджеру не досталось пары, и я встал играть роль сотрудника. До этого всем пар хватало, поэтому к роли сотрудника я был не очень готов…

Моим собеседником оказался молодой человек, назовем его Егор, технический директор небольшой компании.

Цель кейса — донести до сотрудника обратную связь, что отчеты надо присылать вовремя. Егор начал сразу с места в карьер:

— Александр, как же так, почему Вы не присылаете мне отчеты?

Я стоял, думал-думал, чего сказать. И потом ляпнул первое, что пришло в голову:

— Егор, а чего ты хочешь, если ты такой хреновый менеджер?!

Каюсь, я тогда был не в курсе про тяжелые манипуляции. Зато их влияние смог ощутить на себе в полной мере. Егор покраснел, потом пошел пятнами:

— Что значит “хреновый менеджер”?!!! Это недопустимо — так разговаривать с руководством…

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

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

Несколько лет назад, когда я знакомился с сервисом Amazon EC2 была заведена MicroInstance с Ubuntu 10.04 LTS на борту. На ней был поднят Apache и настроено несколько виртуальных хостов, включая блог на MODx Revolution. Выпала тут свободная минутка и подумалось мне, а что будет если на мой потаённый бложик вдруг набежит толпа читателей. Набегать ей в общем то неоткуда, но дух познания, привитый ещё в детстве многократными просмотрами киножурнала «Хочу всё знать», не давал покоя. Мне не доводилось пока участвовать в высоконагруженных проектах, поэтому было проведено небольшое исследование материалов в сети. Из блога в блог кочует утверждение, что необходимо отказаться от использования Apache в пользу Nginx. Это утверждение мне показалось странным, учитывая историю проекта Apache и сообщество разработчиков вокруг него. Неужели разработчики Apache не могут решить проблему ругаемого везде режима prefork? Так ли это на самом деле я и решил выяснить. О результатах читайте под катом.

Прочитав недавно статью «Введение в оптимизацию. Имитация отжига» захотел принять участие в сравнении алгоритмов оптимизации. Но ведь их действительно хорошо бы сравнить. А в материалах исходной статьи не приводится никаких количественных данных. Значит, подумал я, надо сначала сформулировать критерии сравнения. Чем и предлагаю заняться в данной статье.

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

Почему ты не можешь дать точную оценку трудоемкости разработки?
Почему ты не можешь завершить все работы в два раза быстрее?

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

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

Если вам когда-нибудь приходилось разрабатывать форму регистрации или оформления заказа, то вы знаете, что для получения из формы качественных данных нужно прикрутить множество проверок для ФИО, почтовых адресов, e-mail, телефонов. При этом так уж исторически сложилось, что разработчики пишут код валидации информации каждый раз заново. Ну а потом эти проверки приходится еще и поддерживать, а на поддержку, как известно, приходится 80% усилий.

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

Так не должно быть.

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

В этой статье я постараюсь максимально доходчиво рассказать о таком простом, но эффективном методе оптимизации, как имитация отжига (simulated annealing). А чтобы не быть причисленным к далёким от практики любителям теоретизировать, я покажу как применить этот метод для решения задачи коммивояжёра.

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

«Только со смертью догмы начинается наука.»
// Галилео Галилей

«Я начал завидовать рабам. Они всё знают заранее. У них твёрдые убеждения.»
// х/ф Марка Захарова «Убить дракона» по мотивам пьесы Евгения Шварца

Уже пару лет и дня не проходит, чтобы я не услышал (или не прочитал) от людей, начинающих новые проекты, фразу типа «Возьмем серверный движок для REST API и MVC, и погнали». Сначала я думал, что у этих слов есть один источник, может книжку какую завезли во все магазины или где-то в топе поисковиков лежит статья, зомбирующая разработчиков. Если же выяснять у них, что они понимают под REST и MVC, то можно повредиться умом. Ну с MVC уже все ясно, об этом я уже давно писал, ничего не изменилось, только усугубилось, стоит набрать в Google Images «mvc» и мы увидим страшное, стрелочки в любые стороны. Ну а про REST отвечают следующее: ну как же, нам нужно из браузерного GUI и мобильного приложения вызывать серверные методы, например: setUserCity(userId, cityId) или calculateMatrix(data) или startVideoConverter(options, source, destination) а потом мы столкнемся с большой нагрузкой и архитектура REST все решит. Дальше я задаю вопросы, от которых глаза округляются уже у тех, кто недавно еще горел праведной верой, рвался в бой и точно знал, что к чему в этом мире. Теперь можно перейти к рассмотрению терминологической катастрофы, в эпицентре которой мы с вами пребываем.

О чем топик?

В этой статье я расскажу о реализациях разного функционала (преимущественно, на веб-сервисах) для обеспечения безопасности пользователей на примере «гигантов» современной IT индустрии. Данный материал будет полезен разработчикам, архитекторам, тим-лидам и менеджерам при постановке задач схожего функционала. Реализации в статье разработаны командами профессионалов, проверены временем и сотнями миллионами пользователей (а также большим количеством хакеров), хоть и никаких гарантий, что именно данный вариант реализации — абсолютно правильный и 100% безопасный, конечно же нет. Информация основана на личном анализе этих ресурсов.

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

Какие-то статьи по Optical Recognition я пишу давненько, так что пару раз в месяц мне пишут различные люди с вопросами по этой тематике. Иногда создаётся ощущение, что живёшь с ними в разных мирах. С одной стороны понимаешь, что человек скорее всего профессионал в смежной теме, но в методах оптического распознавания знает очень мало. И самое обидное, что он пытается применить метод из близрасположенной области знаний, который логичен, но в Image Recognition полностью не работает, но не понимает этого и сильно обижается, если ему начать рассказывать что-нибудь с самых основ. А учитывая, что рассказывать с основ — много времени, которого часто нет, становится всё ещё печальнее.

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

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

От B2C-порталов ожидается прежде всего масштабирование. К сожалению, масштабирование слишком часто объявляется вопросом Технологии — достаточно выбрать модную технологию и все проблемы решены. То, что это не так, может проявиться, позднее всего, уже в production mode (на рабочей системе).
Вместо того, чтобы махать технологической булавой, расскажу о том, как при помощи продуманной архитектуры и сознательного отказа от модели данных разработать высоко доступный (highly available), масштабируемый (scalable) портал. Первая часть опишет общие концепты, а возможные сценарии и их решения последуют.

Привет %username%! У нас отличные новости: вышла официальная версия NinjaMock — онлайн-сервиса для создания прототипов. Теперь ты можешь рисовать отличные прототипы веб- и мобильных приложений совершенно бесплатно!

История тяжелого проекта: немного о бюрократии, инфраструктуре и процессе разработки ПО

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

Заказчик — довольно крупный инвестиционный банк. Число конечных пользователей: более 10 тыс.

Команда проекта

• более 200 разработчиков (из них 31 тим лид, 7 мастер тимлидов)
• 3 архитектора, один из них главный
• 19 тестировщиков (1 лид, 2 на нагрузочных испытаниях, остальные на функциональном тестировании)
• 5 системных администраторов, в зоне ответственности которых управление СУБД и выше. Администрирование ОС и аппаратной части в зоне ответственности специальной HW team
• переменное число (от 2 до 16) аналитиков, работающих на part time
• 12 технических писателей и переводчиков
• 3 руководителя проекта, постоянно руководит один — второй и третий на подмене во время отпуска, болезни или выступают в качестве ассистента руководителя проекта когда активны и доступны.