fintech-fab / fintech-fab.ru Goto Github PK

Реализовать три модуля:

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

Когда кто-то оставляет заявку на странице http://fintech-fab.ru/vanguard, то по указанному в конфиге email (т.е. мне), уходит письмо о том, что пришла новая заявка. Было бы здорово, если бы автору заявки тоже уходило письмо о том, что как мы рады, что вы подали заявку, и что мы вам обязательно ответим. Еще лучше письмо отправлять в html, вставлять вверху наш логотип (http://fintech-fab.ru/assets/main/logo.png)

Третья проблема для всех веб мастеров и держателей сайта - Сериализация данных
Информации в интернетах много, однако в большинстве своем она текстовая, написана в статье, блоге форуме
Или еще хуже в PDF
А владельцу сайта имеющему 50 000 товаров нужно добавить описание и свойства для каждого товара
создав универсальный текстовый парсер, можно эту задачу облегчить. Благо Яндекс создал такой парсер называется ТОМИТА
Однако для рядового пользователя или держателя сайта, этот инструмент слишком сложный. Если создать прослойку между желаниями клиента, и Томитой, то можно просто и удобно сериализовывать любые данные

http://habrahabr.ru/post/220775/
И каталог с флибусты

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

Например, человек снимает квартиру, заходит на то же самое авито и видит - тут риэлтор, там риелтор. А где реальные продавцы? Куда все делись?
А ведь првоерить средствами программного анализа возможно.
Если у человека есть 2 объявление о продаже квартиры и там указано 2 одинаковых телефона - он риэлтер, и он не собственник.

Т.е. задача сводится к поиску контактов и квартир, которые употребляются на одном ресурсе единожды.
Собственник будет продавать одну и ту же квартиру , а риэлтер несколько.

Данную систему можно применять и к барыгам автомобилей.

Сразу скажу, идея не моя, только что подсказали мне. :)

(фриланс?, ю-ду?)

Названия маршрутов (as) в киви-гейте и киви-шопе префиксовать.
Иначе при подключении пакетов, "забиваются" названия типа "createOrder", "accountIndex" которые по имени никак не относятся к пакетам киви.

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

Это выглядит примерно так:

Или - то же самое событие, но с другими условиями, когда система получает два решения одновременно:

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

Калькулятор будет получать события по http-запросу или из сервера очередей.
Входящее событие представляет собой строковый код (sid - уникальное имя события - я на улице), и набор уточняющих данных (я мокрый, идет дождь).

Калькулятор хранит правила, по которым он будет принимать решение. Для последней схемы - на одно и то же событие "я на улице" будет два правила::

// правило первое
| 1 | im_on_street | rain === true | go_home |
// правило второе
| 2 | im_on_street | rain === true AND umbrella === true | use_umbrella |

Выражение rain === true является псевдо-языком, который означает, что "если в данных события есть ключ rain и он равен true".

В данном примере при входящем событии сработают оба правила, следовательно калькулятор должен отправить два сигнала - go_home и use_umbrella.

Предметная область (базовая схема таблиц в базе данных):

Условия реализации:

Задача должна быть решена на основе Laravel в виде пакета (http://laravel.com/docs/packages)

Задача в том, чтобы сделать более симпатичную и функциональную верстку для раздела регистрации/авторизации.

Сейчас это выглядит так: http://fintech-fab.ru/registration

Для решения задачи использовать подключение библиотек и плагинов:

jQuery
https://code.jquery.com/

Bootstrap3, FontAwesome, Bootswatch
http://www.bootstrapcdn.com/

Результат задачи - это несколько html-файлов, которые подключают все необходимое с указанных выше ресурсов. Также могут иметь свои общие *.css и *.js файлы.

1. Разобраться как подключаются указанные выше ресурсы, в целом посмотреть примеры реализации разных штук на bootstrap3, научиться конструировать html-страницу.
2. Форма авторизации и регистрации не должны быть отдельными страницами, а должны подключаться в виде модальных окон на любой странице проекта.
3. Форма авторизации это поля ввода логина и пароля, а также ссылки для входа через социальные сети.
4. Форма регистрации это поля ввода email плюс пароль (с повторением пароля).
5. Каждая форма должна предусматривать вариант отображения с ошибками (когда на одном или нескольких полях возникает ошибка ввода неверных данных)
6. В каждой форме событие submit должно перехватываться через javascript и данные должны "отправляться" на сервер в JSON-формате.
7. От сервера ожидается два варианта ответа - либо успешная обработка (код ответа 200), либо список ошибок, указанных к каждому из полей (код ответа 400). Эти варианты требуется обрабатывать.
8. Т.к. задача не включает участие сервера, вместо отправки данных на сервер выводим предполагаемо отправляемые данные в console.log
9. Также сами генерируем варианты ответа от сервера, как-будто бы он их вернул.

По реализации - вопросы в скайп.

Сейчас с сайта может быть отправлено одно письмо (заявка на стажировку). Возможно, скоро будет два (см. задачу #8 - приветственное письмо автору заявки на стажировку). Потом еще, и еще... Хочется чтобы отправка писем была собрана в одном месте. Нужно сделать класс-"компонент" (директория для классов-компонентов - FintechFab/Components), куда перенести отправку писем. Компонент должен работать примерно так:

$mailSender = new MailSender();
$mailSender->setParams(array(
  'to' => получатель,
  'name' => имя получателя,
));
$mailSender->doVanguardOrderAuthor();

что означает отправку приветственного письма автору заявки. Т.е. метод doVanguardOrderAuthor отправляет вполне конкретное письмо.

VeeSot
Да проект то хороший,но тут на старте надо всю структуру продумывать.То бишь расписание,преподователи,курсы,ученики,тестирование.
А это нужно еще и продавать?)Для начала надо иметь набор свойств и возможностей чтоб хоть кто то это юзал.А потом уж можно продавать (например http://www.efrontlearning.net/ и его фришная версия).
Поюсом надо определить цель - российские учебные заведения(потеснить мудл в российских учебных заведениях) или сразу на весь мир?

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

VeeSot
Да я понимаю что Вас интересует профит.Но тут можно разработать бесплатную версию и дополнительно версию с фичами.Надстройку.Как уже в упомянутом e-Front
Тут по сути надо быть адептом онлайн образования чтоб черпать некоторые уже существующие идеи из таких проектов как Coursera/Udacity/Lectorium/Universarium(тысячи их),но сделать свою,с домино и медведями =)

mikanoz
Можно я свою мысль скажу. Чтобы продать что-то полезное, надо сначала сделать что-то полезное. Самое полезное получается когда команда думает о клиентах и радостных пользователях, а не о том, как их потом развести на деньги :-) Мотивация разная, результат разный. Опенсорс силен именно этим подходом (думать о профите). И в итоге получаются классные вещи, которые ввиду своей классности, имеют весомые шансы дать возможность и заработать (на поддержке, на консультациях, на том, что в резюме написано). Авторы Laravel сделали действительно классную вещь и теперь очень хорошо зарабатывают, и вовсе не на том, что они эту вещь продают.

Вторая проблема, для будущего пользователя интернета.
Выбор товаров и услуг.
Предложений миллион, а какое из них выгоднее по цене ХЗ
Имея глобальный агрегатор можно собрать цены со всех ИМ и показывать данный товар в с самой выгодной ценой.

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

Совсем нету нормальных приложений для удобного мониторинга и слежки за проектами.
Последнее нововведение - 1 автоответ на проект стоит 10 рублей( 100 проектов в день - 10 р за ответ - 1000р вдень на отвоответы или 30тр в месяц - ну них себе)

Можно сделать приложение на AngularJS для моб устройств (веб версия)- где будут бесплатные автоответы и которое будет пищать при добавлении проекта с нашей специализацией (что бы не упустить проект) + уведомления в случае личных сообщений или когда заказчик нам ответил. Потом приложение с помощью PhoneGap перенести на iOS / Android. + прикрутить смс уведомления (если чувак не качает прилу а юзают веб версию приложения что бы уведомлять его - за смски конечно же он платит сам)

Есть такой кормительный сервис: http://www.obedvofis.info/menyu.html
Там все хорошо, но неудобно делать групповые заказы, т.к. отдельно приходится у каждого человека узнавать что он будет, а потом уже делать общий заказ.

Задача в том, чтобы сделать:

• парсинг меню
• сохранение меню в базе
• рассылка напоминание о том, что можно сделать заказ на обед
• интерфейс выбора из меню нужных пунктов
• по наступлению "часа икс" формирование общего списка заказа на завтрашний день
• отправка общего списка заказа на email

В рамках задачи:

• создать отдельный раздел на сайте: http://fintech-fab.ru/dinner
  • (отдельная директория для контроллеров и view)
• ограничить доступ к этому разделу только сотрудников (роль 'employee')
• создать artisan-команду для сбора данных с obedvofis.info
  • разбирать excel, сохранять в базу
  • после сбора данных - отправка email-ов всем пользователям с ролью 'employee' напоминание и ссылку на раздел.
• создать модели (и таблицы):
  • dinner_menu_items (меню по дням)
  • dinner_menu_users (выбор пунктов меню пользователями)
• при заходе в раздел - показывать список меню и дать возможность выбора одного или нескольких пунктов
• фиксировать выбор в течение сегодняшнего дня (с 8.00 до 16.00)
• создать artisan-команду для формирования общего заказа на основе выбранных пунктов меню за текущий день
  • отправлять общий заказ на email, указанный в конфиге

Задавать вопросы, если что-то непонятно или если будут другие варианты по реализации.

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

Как я это вижу.

• Возникает необходимость провести мероприятие
  • Признаки - название, предварительное время, утвержденное время, онлайн/офлайн, описание
  • Логический признак - множественный выбор - возможные дни проведения (от завтрашнего + 7 дней)
• На странице выводится список этих мероприятий
  • Маркируются: время утверждено, время не утверждено, в архиве
• Для мероприятий, на которые не утверждено время, доступен блок утверждения

Блок утверждения.

• Список дней (дни, которые выбраны при создании мероприятия)
• Список диапазонов времени (9-12, 12-15, 15-18, 18-21)

Процесс утверждения

Авторизованный пользователь (доступ для авторизованных не ограничивается), может выбрать подходящий ему день и время.
После выбора, он может выбрать снова (перезаписывается).
По каждому новому результату выбора, пересчитывается "предварительное время". Когда количество заявок достигает значения более чем X (допустим, 10 человек), и "предварительное время" подходит более чем Y% (предлагаю 50%) заявок, событие автоматически становится утвержденным.

Вопросы, предложения?

Файлопомойка с Web-интерфейсом.

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

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

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

Корректно обрабатывать одинаковые имена файлов и папок, длинные имена, спецсимволы в именах (обратить внимание на разные операционные системы и разные файловые системы).

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

Проект учебный – изучить Laravel. Впрочем можно прикрутить доступ по протоколу WebDAV и проект будет полезен тем, кто работает в больших корпорациях (интернет лимитирован, открыт только 80 порт, т.е. никаких ftp и p2p, а всякие дропбоксы забанены).

Здесь есть анкета стажера: http://fintech-fab.ru/vanguard
Надо ее сделать поточнее, а именно - из полей:

1. Как звать/величать - оставляем как есть
2. Список чекбоксов с выбором технологий "В каких направлениях хотите стажироваться" (php, верстка, android, ios, другое)
3. Текстовое поле "Что успели сделать на практике"
4. Короткое текстовое поле "Сколько ч/нед есть на стажировку"
5. Чекбокс "Могу раз в неделю приезжать к вам в офис"
6. О себе - оставляем как есть.
7. Email для ответа - оставляем как есть.

Все поля должны как и сейчас - приходить на почту.

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

inTour - вам в помощь. Он должен быть в смартфоне каждого туриста.

Вы заходите в inTour, и он показывает вашу позицию на карте, ближайшие объекты(кафе, музеи, театры и т.п.) к вам. Нажав на объект - мы можем можем посмотреть отзывы, фотографии которые пользователи сделали тут, оценка места, стоимость билета/средний чек или фото чеков пользователей.

Так же просмотреть ближайшие объекты можно в виде списка. Обьекты можно групировать в зависимости от того, что хочет пользователь - покушать / шоппинг / посмотреть достопримечательности города и т.п.

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

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

Так же после посещения объекта пользователь может сам оставить отзыв, сфотографировать чек (если магазин/кафе) или ввести стоимость входного билета, прикрепить фотографии этого места и выбрать свою оценку.

inTour - подобие нового сайта фидбэков. Только в новом, интересном формате.

Вариант развития #32 но про еду. По геолокации или по клику/тапу на карте (например googlemaps) выводиться список самых известных блюд местной кухни а также список мест где эти блюда можно съесть и примерные цены....
среда разработки ? как вариант angularjs или Ext JS?

В наших проектах, иногда возникают разные проблемы, о которых необходимо срочно извещать разных сотрудников, которые работают в компании. На сайте fintech-fab.ru хочется иметь удобный интерфейс для рассылки подобных сообщений (email + sms). Сейчас уже есть регистрация и авторизация, а также "раздача" прав через административный интерфейс.

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

1. Тщательно разобраться, как работает регистрация и управление ролями. Есть Роли и Пользователи. У каждого Пользователя может быть несколько Ролей.

• В системе, когда решается, можно ли Пользователю выполнить какое то действие, проверяется его Роль.
• В данный момент реализованы три роли (чтобы заполнить таблицу ролей, запустите команду php artisan db:seed).
• Чтобы зарегистрироваться, перейдите по ссылке /registration и заполните форму.
• Чтобы зарегистрироваться через социальную сеть (необязательно), зарегистрируйте приложение в соц. сети (фейсбуке или вконтакте) и настройте конфигурационный файл app/config/local/social.php (в директории app/config/examples есть примеры конфигурационных файлов).
• После регистрации, в базе данных через таблицу user_role назначьте своему пользователю роль 'admin'.
• В итоге вам будет доступна ссылка /admin.

1. Добавить в систему новые роли (через миграции)
2. Создать новый раздел для Отправителей, где я, например, как отправитель, могу:

а) выбрать тему из списка (или написав текст в текстовое поле, тем самым завести новую тему)
б) если хочу, написать комментарий
в) выбрать получателей
г) нажать кнопку "отправить"
д) получателям уйдет подробный email (тема, отправитель, другие получатели) и sms-сообщение (только тема).

Типа 1С?

Базы лежат в XML, DBF форматах на nalog.fias.ru.
Cвободный доступ: http://fias.nalog.ru/

Делаем модуль выявления мошеннических операций.

Некая система Мерчанта (продавца, который осуществляет платежные операции) совершает платежные транзакции и перед тем, как выполнить платеж, запрашивает у модуля расчет степени мошенничества по каждой транзакции. Модуль на основе истории запросов и правил фрода, рассчитывает степень мошенничества (очки фрода) и предлагает действия (заблокировать, или только уведомить).

Основа для выявления - это анализ всех предыдущих операций.

Например, по Мерчанту и точке продажи номер 1 проходит 100 платежных операций в день на общую сумму в среднем 100 тыс. руб.

В модуль вносим правило [1], что в случае превышения средних значений на 20% за 24 часа, необходимо блокировать все транзакции этого Мерчанта.

Также вносим правило [2], что с одного номера карты в данной точке продажи нельзя совершать более 1 операции за 12 часов (блокируем только эту транзакцию).

Изначально модулю неизвестна статистика предыдущих операций по данному Мерчанту и точке продажи, поэтому правило [1] может сработать только на следующий день, а правило [2] может сработать сразу, как только по номеру карты произойдет вторая транзакция в течение 12 часов.

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

Также присутствует возможность ручной блокировки по значению любого поля.

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

FraudBlock - это блокировки, которые могут быть внесены вручную или автоматически.

from_id | источник блокировки
active_to | можно назначить дату, до которой действительна блокировка
field | на какое поле запроса действует блокировка
value | на какое значение поля действует блокировка

Например, блокируем вручную (from_id) мерчанта (field=merchant_id) номер 123 (value=123)
И если приходит транзакция с такими данными, то блокируется безусловно без проверки по правилам.

FraudRequest - это данные, которые приходят в запросе от Мерчанта на расчет фрода.

merchant_id | мерчант
point_id | id точки продажи
transaction_id | id транзакции
transaction_type | тип транзакции
amount | сумма транзакции
currency | валюта транзакции
pan | полный номер карты
bin | бин карты (первые 6 цифр из номера)
system | платежная система (виза, мастеркард и т.д)
type | типа карты (кредитная, дебетовая, виртуальная и т.д.)
ip | с какого ip совершается операция
country | из какой страны совершается операция

FraudLimitRule - данные для правила

name | название правила
actions | требуемое действие (уведомить, заблокировать, начислить очки - может быть все одновременно)
target | поле, на которую направлено действие (мерчант, точка продажи, транзакция, etc)
score | начисляемые очки фрода
field | поле, по которому рассчитывается фрод (мерчант, точка продажи, бин карты, etc)
amount | указывается для расчета фрода на сумму транзакций
quantity | указывается для расчета фрода на количество транзакций
period | количество времени (в минутах), для расчета по периоду
percentage | чекбокс, если требуется расчет отношения количества/суммы по отношению к предыдущему периоду
value | вспомогательное значение для расчета

Примеры правил на человеческом языке:

Уведомить о риске на точке продажи, если по точке продажи номер А происходит превышение общей суммы продаж на 20% по сравнению с предыдущей неделей.
Заблокировать Мерчанта, если по Мерчанту номер Б произошло увеличение количества транзакций на 50% по сравнению с предыдущими 24 часами.
Заблокировать bin карты, если по данному bin происходит продажа чаще, чем 100 раз в течение часа.
Уведомить, если на точке продажи произошла операция на сумму более 10 тыс. руб.
Уведомить, если по Мерчанту произошли операции количеством более 300 штук в течение одного часа.

У гитхаба есть API (https://developer.github.com/v3/)
В Laravel есть консольные команды (http://laravel.com/docs/commands)
Нужно сделать такую вещь:

• запускается консольная команда
• подключается к api github-а
• собирает информацию о репозиториях компании финтек-фаб и о группе стажировки
• сохраняет ее в базу в структурированном виде (продумать самостоятельно)
• в разделе на сайте выводит эту информацию.

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