Будьте добры, поделитесь секретом, как вы синхронизируете структуру MySQL на development и production? Нашел три варианта:

• Записывать SQL в файлик
• Использовать скрипт для сравнения структур (PHP) — Database structure synchronizer
• Использовать синхронизацию структуры двух БД в SQLyog MySQL GUI (Enterprise Edition)

Что делать в ситуации, когда приходиться откатывать svn в тот revision, где использовалась критически отличающаяся структура MySQL?

Вопрос о стилизации <input type=«file» /> настолько стар, что наверное только ленивый не пробовал собственную реализацию этого, несомненно, важного в web дизайне элемента.
Однако, в большинстве своём, решения очень не однозначны и зачастую предлагают примерно следующие варианты:

• Наложить файл инпут поверх картинки и сделать его прозрачным.
• Использовать flash.

При этом, в первом случае, чтобы всё работало относительно одинаково во всех браузерах, предлагается «спорные области» — те что в одном браузере являются активными для нажатия, а в другом неактивными — закрыть, например, наложив сверху <div></div>. Стоит ещё добавить, что тут же используется значительное количество css со всяческими отрицательными отступами и float`ами.
А во втором случае мы имеем ряд не удобств связанные с активацией flash элементов (например в IE), а лично у меня (и думаю у всех, кто в ФФ использует Add Block Plus дополнение) кнопочка block совсем не красит флешевый инпут файл.

Хочу представить на суд хабрасообщества концепцию информационной системы.

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

Мне очень интересно работать в данном направлении, хочется создать бесплатный и открытый аналог существующим системам и получить ценный опыт разработки. Пожалуйста не пишите комментарии типа «Не стоит создавать еще один велосипед» или «Комания X и комания Y уже сделали это и успешно продают», но мне будет интересно посмотреть аналоги.

На данный момент существует несколько классов информационных систем:

Последние пять лет я работаю в тех. саппорте. И у меня сложилось некоторые принципы, следование которым, на мой взгляд, сделает любой тех. саппорт клёвым и офигительным. А если им не следовать, то саппорт будет унылым и неклёвым.

Сразу поясню, что эти советы/правила больше относятся к саппорту через HelpDesk или e-mails, у телефонной поддержки есть некоторые свои особенности.

1. Быстрая реакция и ответы

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

К сожалению быстрый саппорт, доступный 24/7, это дорого: нужно больше людей и нужна круглосуточно доступная инфраструктура. Чаще всего это просто невыгодно, особенно если вы не крупная корпорация, а маленький стартапчик.

В этом случае нам поможет одна интересная штука.

Задача: организовать поиск по всему сайту затратив как можно меньше усилий и оформить результаты в своем стиле.

Рассуждение
Есть различные серверные системы для организации полнотекстового поиска индексируя сайт, индексирую базу данных. Но их надо устанавливать на своем сервере, настраивать, а некоторые из них еще и платные.
В какой-то момент решил воспользоваться Google Ajax Search API через JavaScript, но тут вид результатов менять достаточно сложно, да и еще надо делать запросы в другой домен при помощи javascript.

Решение
В итоге набрел на странице Google AJAX Search API в раздел Code Snippets и все стало просто: немного кода на php и полнотекстовый поиск по любому сайту готов.

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

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

Навеяно темой Cisco: Пути сертификации неисповедимы.

1. Подготовка к 640-802. Теория.
2. Подготовка к лабе. Практика.
3. Подготовка к экзамену. Регистрация и порядок.
4. Сертификат.

1. Подготовка к 640-802. Теория.

Для получения статуса CCNA существует два пути — это экзамен 640-802 или пара 640-822 + 640-816. В данном обзоре рассматривается исключительно первый вариант, в терминологии циско т.н. композитный экзамен(13).

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

1. Начать с «терминов и определений»
Есть несколько вариаций этого способа:

Можно приводить общеизвестные определения, намекая, что присутствующие не совсем адекватны:

Хотим ли мы единой регистрации – да, конечно.

Что у нас есть

openID

«Давайте, централизуем регистрацию» — что может быть проще и… ограниченней.
Во-первых, я должен регистрироваться (всеравно регистрироваться!) на сайте провайдера.
Во-вторых, запомнить еще один логин и пароль.
В-третьих вводить этот логин и пароль.
— древнее унылое поиск и сопоставление 2-х ключей в базе данных. Просто базы теперь пересекаются (кстати, полагаю с этим есть проблемы).
В-четвертых openID может выглядеть вот так «красиво»: technorati.com/people/technorati/username

E-mail

Забавно, большинство вариантов получения openID сами требуют идентификации – по E-mail.
E-mail давно является основной любой идентификации, как правильно заметил автор статьи Мгновенная почта и жизнь без паролей.
И опять же правильно заметил что, почтовый интерфейс неудобен для авторизации на сайте. Значит нужно нечто другое, и это Jabber.

Adobe продолжает стимулировать распространение Flex. Помимо бесплатной версии Flex Builder Professional для студентов и работников образования, среду разработки теперь так же можно получить если вы потеряли работу. Для этого можно обратиться к Serge Jespers, Mihai Corlan или Tom Krcha.

За новость спасибо Росту

После прочтения статьи я решил написать декоратор который будет прикреплять jquery код для получения данных из формы и отправки их на сервер.
Своим опытом спешу поделится с хабрасообществом.

Ваш магазин приносит доход. Может ли он быть более прибыльным? Конечно, если вы соблюдете, как минимум, те десять пунктов, которые перечислены ниже. Пройдитесь внимательно по этому «чек листу» и у вас, наверняка, найдется пару замечаний к своему магазину. Порой даже большие и солидные интернет-магазины допускают такие детские ошибки.

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

1. Главная страница выглядит блекло и безлично
Что видит ваш посетитель, попадая на главную страницу магазина? Может ли со 100% уверенностью сказать, что это интернет-магазин? Может ли он узнать, чем торгует этот магазин? Типичной ошибкой является пренебрежение к законам коммерческого дизайна. Помимо мелкого шрифта и отсутствия должного описания, часто не всегда удается найти центр композиции. Все тексты и картинки выглядят или второстепенным или же каждый элемент пытается «перекричать» соседний. Вспомните, как выглядит газета бесплатных объявлений, заполненная массой пестрых рекламных блоков.

Пожалейте время и глаза своего посетителя — он задержится дольше на вашем сайте и, возможно, сделает заказ.

2. Видны ли способы связи с менеджерами?
Одним покупателям проще прийти в магазин и самим отыскать товар на полках, другим же удобнее прямо с порога спросить продавца о наличии и стоимости. Даже если ваш магазин создавал профессиональный дизайнер, проконтролируйте, чтобы тем, кому удобнее позвонить или написать вам, изложив свои вопросы, не пришлось долго искать, как это сделать. Идеальным вариантом будет номер телефона, который всегда навиду. Например, в верхней части страницы.

3. Есть ли информация о способах оплаты и условиях доставки?
Стоит ли посетителю тратить время на поиск товара в вашем магазине, если он не имеет возможности оплатить теми способами, которые вы можете принять? Стоит ли тратить время, если вы не сможете доставить оплаченный товар вашему покупателю? Ответы очевидны — вы не можете обслужить такого клиента, также как не сможете обслужить тех, кто не смог найти информацию о способах оплаты и доставки на вашем сайте. Даже если последние живут в квартале от вашего офиса, и имеют возможность оплатить, они об этом не узнают.

За хорошие манеры можно принять наличие пункта об оплате и доставке на видном месте.

4. Удобны ли способы оплаты и доставки для вашего потенциального клиента?
Даже если информация о том, как оплатить, куда и за сколько вы доставите, висит на самом видном месте, ваш посетитель может уйти разочарованным из-за

Хочу поделиться своими мыслями по поводу организации фильтрации входных данных (php).

Первая мысль — это разработка классов-обёрток String, Integer, Float, Array для стандартных типов. Данные классы предназначены для более удобной работы со строками, массивами и т.п., а так же для применения их в фильтрах входных данных.

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

Для чего

Бывает так, что человек хочет начать свой бизнес. И не редко бизнес у человека начинается с регистрации ООО или ИП.
В принципе, ему достаточно зайти на сайт 46-й налоговой и скачать специальную программу для подготовки документов. Вбить все необходимые данные, распечатать, сшить, заверить у нотариуса и отвезти в налоговую. Хотя, кроме неспосредственно заявления, необходимы и еще несколько документов — решение, протокол и учредительный договор (если учредителей несколько) и др., но примеров в интернете достаточно.
Но у многих просто не хватает времени. Но даже, если время есть, ошибок может быть много и в регистрации человеку будет отказано. Юристы, занимающиеся этим постоянно, уже знают все нюансы и сделают это правильно.
Поэтому большинство людей обращаются в юридические фирмы за помощью. В таком случае происходит следующее: Человек приезжает к юристу, сообщает ему все необходимые данные и уже юрист грамотно составляет все необходимые документы. На следующий день человек забирает документы, заверяет свою подпись на этих документах у нотариуса и отвозит их в регистрирующий орган.
Сервис задуман для того, чтобы избавить человека от поездок к юристу. В любое удобное для себя время он заполняет на сайте форму, оплачивает услуги юристов любым удобным для себя способом и получает весь комплект документов с подробными инструкциями к дальнейшим действиям.

Для кого

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

Теперь буду надеяться, что сервис действительно будет полезным.

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

P.S. Сайт еще тестируется, поэтому, если обнаружите ошибки, сообщите пожалуйста.

Зачем нужны камеры наблюдения? Правильно — чтобы наблюдать за происходящим и контролировать ситуацию! В наше неспокойное время эти самые камеры развешаны повсюду — от денежных хранилищ до придорожных кафе. Однако защищая свои владения, хозяева порой забывают о защите самой камеры путем банальной установки пароля на доступ из Интернета. И очень зря. Если пароль не установить — ваша камера «безопасности» превращается в публичную вэб-камеру с реалити шоу для всех желающих.

Проект «Модель данных» (fishbolt.model). Ядром архитектуры является концептуально новая модель данных. Модель представляет собой альтернативу существующим подходам к организации структур данных в Java-приложениях, таким как Plain Old Java Object (POJOs), Enterprise JavaBeans (EJB) и другим. Преимущества модели по сравнению с существующими подходами состоят в том, что она является более гибкой с точки зрения добавления новой или изменения существующей функциональности, более информативной с точки зрения возможности анализа структуры данных програмными средствами, а также обеспечивает выявление большинства ошибок, связанных с изменениями в структуре данных, на этапе компиляции, а не на этапе выполнения.

Проект «Расширения модели данных» (fishbolt.model.ext). Эффективный механизм расширений модели позволяет легко добавлять в модель новую функциональность. Fishbolt предлагает ряд полезных расширений модели, которые включают в себя:

* механизм отслеживания и обработки событий в модели
* механизм проверки (валидации) вводимых пользователем значений
* механизм сортировки данных и др.

Проект «Провайдеры модели» (fishbolt.model.provider). В модели предусмотрена возможность интеграции с различными источниками данных. За интеграцию с источниками данных отвечают провайдеры модели. Провайдеры модели являются абстракцией. Интеграция с тем или иным источником обеспечивается конкретной реализацией провайдеров. Fishbolt предлагает две реализации провайдеров:

* проект «Реализация модели в памяти» (fishbolt.model.memory) – обеспечивает хранение данных в оперативной памяти. По завершении выполнения программы эти данные бесследно теряются. Данная реализация удобна для тестирования разрабатываемого ПО.
* проект «Реализациия модели с использованием Hibernate» (fishbolt.model.hibernate) – обеспечивает взаимодействие с базами данных через технологию Hibernate.

Для обеспечения интеграции с Hibernate предназначены два (вспомогательных) проекта:

* проект «Паттерн Команда и Hibernate» (fishbolt.hibernate) – при помощи паттерна Команда инкапсулирует управление Hibernate-сессиями и транзакциями, так что клиент библиотеки fishbolt.hibernate может больше не беспокоиться об этих вещах. Библиотека fishbolt.hibernate может использоваться независимо от модели данных fishbolt.hibernate.model в любых Java-приложениях, в которых применяется технология Hibernate.
* проект «Hibernate-аннотации в модели» (fishbolt.model.hibernate.annotations) – обеспечивает поддержку Hibernate-аннотаций в объектах модели данных.

В основу различных идей и подходов, на которых базируются модель и ее расширения, легли такие известные паттерны проектирования, как «Адаптер», «Команда», «Слушатель», а также специально разработанные паттерны – «Набор флажков», «Менеджер» и «Представитель значения». Реализации перечисленных паттернов содержатся в проекте «Паттерны общего назначения» (fishbolt.common).

На уровне представления (presentation tier) Fishbolt обеспечивает интеграцию модели с различными технологиями и платформами:

Платформа Eclipse. Проект-плагин «Интеграция с платформой Eclipse» (fishbolt.model.eclipse) позволяет легко и быстро разрабатывать пользовательские интерфейсы для прикладных моделей данных, используя компоненты пользовательского интерфейса, предоставляемые платформой Eclipse. Плагин поддерживает как простые компоненты из набора Standard Widget Toolkit (поля ввода, выпадающие списки и т.д.), так и сложные компоненты из набора JFace (редакторы, визарды, таблицы, деревья и т.д.).

Кроме плагина fishbolt.model.eclipse, Fishbolt предлагает еще несколько Eclipse-плагинов, которые вместе образуют фреймворк для построения многоуровневых приложений на платформе Eclipse. Подробнее об этих плагинах см. «Интеграция с платформой Eclipse».

Язык шаблонов FreeMarker. Проект «Интеграция с языком шаблонов FreeMarker» (fishbolt.model.freemarker) обеспечивает возможность генерации отчетов на основе данных, содержащихся в модели, с помощью шаблонов FreeMarker.

В настоящее время Fishbolt ведет разработку проектов, призванных значительно упростить построение пользовательских интерфейсов для прикладных моделей данных в среде Netbeans (на основе библиотеки Swing) и в веб-приложениях.

Смотри детали на fishbolt.ru

Начинать данную статью с различных вводных матчастей о «Великой силе SCRUM'а» и «ущербности водопадной методологии» считаю пустой тратой времени, поскольку в интернете и так достаточно много ресурсов, позволяющих узнать всё: от историй предпосылок создания технологий до всех преимуществ и недостатков в текущих реализациях. Как говорится: «Кто ищет, тот всегда найдет...» (с) :-).

Хочу поделиться неким опытом и даже скорей всего своим мнением о «существующем зоопарке ПО» в некоторых ИТ-компаниях, а именно подходах и реализациях.

Итак, начнем…

Естественно, для написания нового или улучшения существующего продукта предварительно нужно исследовать рынок, проанализировать потребность заказчиков, написать кучу каких-то нелепых концепций и ТЗ, в которых для «большего страха и мощи системы» необходимо как можно больше применять такие выражения как: «… на основе существующих артефактов, разработанная метамодель поможет реальным пользователям ...», обязательно использовать только термины и аббревиатуры и конечно же обязательным условием является описание «сферических коней в вакууме». Затем надо детально проанализировать все эти концепции, обрасти еще миллионами моделей: от простых IDEF-диаграмм до огромных UML-моделей со всякими ассоциациями, агрегациями и прочей «атрибутикой». В итоге получаются все новые и новые «пауки». Конечным пользователям глубоко наплевать на эти модели, диаграммы и т.д., им нужны рабочие кнопки…

После этого начинается непосредственно разработка, программисты начинают «клепать» то задуманное, о чем писалось в ТЗ. Опустим документирование и тестирование… перейдем сразу к выходу продукта на рынок. Маркетологи разработали кучу бумажек о выходе продукта «СуперМегаСистемаПро», которая позволит не только быть «системой, автоматизирующей то-то и то-то», но также (причем без лишней скромности)… она… она… она вообще позволяет «автоматизировать весь мир» :-). Вроде все хорошо, система мощная, современная, но почему-то заказчики недовольны… вроде система обо всем, а на самом деле не о чем. В итоге существующие продукты начинают ругать все кому не лень, а внедренцы в тихоря при помощи SDK (если есть) «клепают» все новые и новые плагинчики, лишь бы заказчик был доволен. Следствие, зоопарк разрастается…

Существующие проблемы ПО находятся прямо «на поверхности», их не надо искать, а уж тем более вытаскивать из глубины. Но тем не менее, начинаются новые обсуждения, новые концепции… в итоге «кто в лес, кто по дрова»… но главное, существующие недостатки завуалированы емкими терминами и как следствие новая система только стала еще сложнее и не понятнее. Жалко потраченного времени (2-5 лет), а уже тем более жалко выкидывать «тонны кода», ведь программисты не виноваты.

После разведенной мною демагогии о «водопадном подходе» :-) имеет смысл перейти к реально рабочей технологии SCRUM. Данная технология действительно помогает оживлять продукты и способствует разработке новых и качественных продуктов.

Инициативная группа разработки решила поработать по SCRUM, пытаясь исправить существующее положение вещей. Была сформирована команда в составе: программисты, аналитики и тестировщики, в которой как и положено технологии был ProductOwner со своим ProductBacklog'ом и SCRUM-мастер.

Процесс
Практику SCRUM мы объединили с некоторыми практиками XP (eXtreme Programming). SCRUM позволяет решить вопросы управления и организации, а XP специализируется на инженерных практиках. Из XP мы позаимствовали: парное программирование, рефакторинг, CodeReview и стилевое описание кода. Также на ретроспективах мы определили для себя ряд правил, которых мы придерживаемся. Для проектирования качественного GUI применяем практику использования персонажей.

Используем только легковесное документирование: диаграмма БД и UML-модель, которые разрастаются только в ходе разработки, соответственно — это не такие страшные пауки, как было описано выше.

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

Для подсчета идеальных часов мы используем фокус-фактор равный 0.4. В принципе такой показатель является средним по всем итерациям и является оптимальным, поскольку обычно запланированные задачи мы успеваем сделать вовремя.

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

SCRUM — митинг
Ежедневные встречи проводятся 2 раза в день возле SCRUM-доски. После встречи делается отметка на графике сгорания. Задача считается выполненной, т.е. переносится в «Done», только после тестирования. Программист может взять следующую задачу в «InProgress» только после одобрения аналитиком предыдущей задачи, взятой на выполнение. Диаграмму сгорания «подбивает» Скрам-мастер. Чтобы не превышать временной 15-минутный лимит, встреча проводится стоя. На встрече мы определяем, что мы сделали, что будем дальше делать, какие проблемы. Стараемся не обсуждать технические детали, но не всегда получается. Обычно встреча длится не более 10 минут. Если на митинге были определены некоторые технические проблемы, то их обсуждение проводится после скрам-митинга возле «стены проектирования» (доска с маркерами).

SCRUM — доска
В качестве скрам-доски мы используем обыкновенную пробковую доску. Область доски мы разделили на три части: ToDo (что надо сделать), InProgress (В работе), Done (Выполнено).

Однако, мы ведем и электронную версию доски (UserStory, задачи, % участия задействованных участников команды и т.д.) в программе. Это делается «для истории», в работе мы пользуемся только доской.

График сгорания
График сгорания является наглядным индикатором прогресса. Ось X — это ось времени. Ось Y — трудоемкость невыполненных задач. Задача считается выполненной если она проверена тестировщиком, во всех остальных случаях задача не выполнена.

Выполненные задачи переносятся в раздел «Done» скрам-доски. Таким образом график отображает сумму трудоемкости задач, находящихся в разделах «ToDo» и «InProgress». После ежедневных митингов, диаграмма сгорания «подбивается» с учетом выполенных задач за день. Также информация о выполнении заносится в программу, в которой наглядно отображается дата взятия задачи в «InProgress», дата выполнения данной задачи. В продукте автоматически подсчитывается средняя скорость команды, фокус-фактор. Данная информация иногда может помочь в переоценке трудоемкости задач и фокус-фактора команды.

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

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

Для проведения ретроспективы используем доску с маркерами, которая условна разделена на 4 блока: минусы, плюсы, идеи и план. После того как все участники высказались и все идеи были записаны, мы проводим голосование путем расставления магнитных фишечек. Практически все, что было записано в блок «План» мы стараемся впоследствии соблюдать.

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

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

• Большая часть российских банков требует передачи cvv/cvv2 при каждой транзакции (прощай PayPal).
• Банк находится в России – отдельные банки не проводят наши кредитки.
• Вводить номер кредитки на сомнительных сайтах совсем не хочется. (Хотя это верно не только для отечественных кредиток)

Что нам позволяет Entropay:

• Создавать виртуальные кредитные карты VISA, которыми можно расплачиваться практически на всех сайтах и использовать на PayPal.
• Переводить деньги с обычных кредиток на виртуальные.
• Переводить деньги между виртуальными кредитками.

Скажем, если мне требуется оплатить услугу на сайте, который вызывает у меня недоверие, я могу:

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

Собственно Entropay, помимо решения для проблем с оплатой отечественными кредитками это одно из самых мощных, на мой взгляд, средств защиты от фишинга.

UPD: Entropay снимает 4.95% за ввод средств. Больше никаких оплат, в т.ч. за ведение карты, не берется.

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