Web/Django инструкция/ментор

Приветствую.

Немного странный топик, но все же. Для начала немного про себя. Фрилансер на ниве VoIP телефонии. Asterisk, FreeSWITCH, Kamailio, вот это все.
В какой-то момент начал понимать, что просто настройку данных систем сделать часто не достаточно, регулярно юзеры просят какую-то мордочку для управления хозяйством, скорее, даже не для управления, а для просмотра статистик и базы данных.
Данных морд для этих систем есть достаточное количество, но в том и хитрость, что каждая контора — какие-то свои требования. И просто даже шаблонами, которые можно редактировать тут не обойтись.
Собственно, для написания таких самых мордочек (по факту — отобразить красиво с графиками результаты SQL запроса + реалтайм состояние системы) и возникло желание/необходимость освоить какой-то фреймворк для фигак-фигак.
Выбор по факту стоит между Yii2(PHP) и Django(Python) потому как эти 2 языка я знаю одинаково плохо (был бы какой-то популярный фреймворк на Lua — он был бы тут же).
Собственно, ищется ментор который за денюжку покажет какие-то базовые вещи (список которых я написал, но не уверен, что написал хорошо) и объяснит как и с чем это едят.

Список вещей (из того, что показалось важным):

1. Пользователи
Логины
Как правильно заводить (создавать) пользователей
Уровни доступа (админы, начальники, рядовые рабы)
Сессии (кто, вообще, где и как)
Куки (запоминание и автологины)

2. Темплейты
Что может
Как может
Чего не может :)
По возможности — как раскрасить и вставить котика (т.е. как правильно прикрутить статику или выдать снежок в динамике, типа админу — снежок, рядовому юзеру — падающие кирпичики)
Выдача информации в разных видах как то (текст, список, таблица, график, картинка, звуковой файл (с плеером))
Базово — AJAX и как с этим жить в примерах (из простого — данные в табличке обновляются каждые N секунд)

3. Формы (я хочу получить от пользователя)
Текстовое поле (циферки, мыло, просто текст)
Чекбокс (да, нет, подумаю)
Выпадающий список
Дата
Переключатель (radiobutton, если помню правильно)
Дать возможность юзеру загрузить файлик (аватарка, любимая песня, csv....)
Также выдать в форме какой-то pre-defined значение типа, если дата — поставить по умолчанию сегодняшнюю, если выпадающий список — на каком-то значении....
Ну и как это все получить на бэке.

4. Подписка на события (опционально)
Подписка на события от внешних сервисов (обычно что-то типа TCP/Telnet соединения)

Ваши предложения/комменты/посылания можно писать тут или в Телеграм — @igor_olhovskiy

PS: Да, я знаю, что можно заплатить кому-то, в перспективе так и планируется, но важно понимать как это все работает для себя. Уровень HA/Scalability порядка сайта для просмотра собачек ближайшими родственниками по выходным, поэтому оптимизации/O(n) и прочее нужно разве что для красоты и удовлетворения эго.
PPS: Вообще в идеале получить какой-то проект/проекты, из которого потом можно будет копипастить на радость себе (в основном касается UI, т.к. последний UI, что я проектировал был на Delphi и это было давно)
PPPS: Работать по этому профилю как основному в жизни не собираюсь :)

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
(был бы какой-то популярный фреймворк на Lua — он был бы тут же

есть Lapis ( leafo.net/lapis ), OpenResty ( openresty.org/en , на основе которого написан Lapis) и github.com/EvandroLG/pegasus.lua (хотя последний наверное малоизвестен, просто сам интересуюсь луа, поэтому знаю про то. что он есть), и еще парочку несколько устаревших (или нет) типа Kepler Project (xavante, orbit и т.д.).
Lapis, по-моему, наиболее известный развививающийся Lua-фреймворк для веба на данный момент.
Хотя да, они (к сожалению ИМХО, ибо думаю, что Lua для веба не хуже пхп и питона) менее известны, чем django или yii.

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

ну если юзерам не принципиален язык, на котором оно написано, то думаю вполне могут подойти те Lua-фреймворки, которые я упомянул.

Спасибо, гляну, хотя первые 2 немного отдают эзотерикой (в смысле крутятся напрямую в nginx)

ну ты ж пишешь, что

PPPS: Работать по этому профилю как основному в жизни не собираюсь :)

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

крутятся напрямую в nginx

ну и вроде это одна из особенностей Lua, насколько знаю.

Вот тут скорее будет важна как раз поддерживаемость тоже. Не так много народу lua знает. Хотя местами очень приятный язык.

и еще, если нужна будет какая-нить база данных для этого дела, то есть Tarantool github.com/tarantool/tarantool , которая написана на Lua (критичные участки — на Си). Даа и Redis насколько знаю хорошо луа поддерживает.

Могу рассказать о базовых вещах в Django ;)

На деле VoIP крайне проблемен разделением зон ответственности, и дебильно-КГБшными порядками в местных щеневмерлах. То есть какая-нить блондинистая сущность наадминит пароль 123, напалить стопиццотыщ на звонках — а крайним выставят тебя.
Я уже молчу, что банально пробросят IP-каналом связь в Лугандон, а потом обвинят тебя что ты её организовал. ИЧСХ, те кто обвинил и те кто пробросил будут очень хорошо знакомы, работая в одном кабинете.

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

Ежели им чё посложнее — то поднимай FreePBX поверх Астериска и пущай играются его веб-мордой. От тебя потребуется разъяснение как и чего, возможно инструкцию напишешь (не за бесплатно разумеется).

Мой совет — подними у себя локально на машине FreePBX, в идеале — образом на виртуалке. Поиграйся посмотри чё оно. И поверь, что трахаться с индивидуальными хотелками юзверей — удовольствие ниже среднего. Они хотят очень много разных «особенностей», притом чтобы ты постоянно переделывал под то что они имели в виду. И главное, это не ценится, они хотят чуть ли не даром.

Почему и говорю — ниши программирования готового софта здесь нет. Есть ниша сервиса, и только она. Для тех кто не может освоить что попроще типа Askozia или VoxImplant.

Ежели всё же рискнёшь — не говори что не предупреждали.

Спасибо за совет, конечно, но я как бы не 1ю неделю (да и не первый год, чего возраст-то скрывать) тут сижу. И к администрированию никого подпускать не собираюсь, разве что под расписку в 3х экземплярах со справкой от психиатра, участкового и владельца бизнеса.
И что такое FreePBX тоже знаю, даже, о ужас, накопипастил пару своих модулей для особо заковыристых задач. Про качество кода говорить не буду, но работает.
В том то и проблема, что стандартного CDR Reports, который есть часть FreePBX часто не хватает, да и смотреть на него сложно, слезы отчаяния глаза застилают.
А задачки как раз возникают, и, как было отмечено, не просто для софта «склонировал с гитхаба, подправил конфиги». Как раз много кто хочет чего-то своего и деньги суют в руки. И часто немалые. И в тех же Украинах. Места знать надо. А с CDR таблицами еще важно знать как работать надо, местным админам часто тонер поменять некогда, не то что SQL запрос написать. А девочка на ресепшене, которая в совершенстве из офисной техники знает только кофе-машину не будет (да и не должна) знать чем SQL отличается от grep.
PS: VoxImplant — то еще говнище, знавал его еще под именем Zingaya. Но тут проблема скорее не в самом сервисе, а в том, как они про себя рассказывают и что получается в итоге.

Ну, говнище оно по большому счёту всё. Большего говна чем в VoIP я не встречал ни в одном коде, вот так чтобы из говна и палок было буквально, кроме говна и палок вообще ничего.

Слова «надо знать как работать» можно применить ко всему абсолютно. Равно как и задачки бывают вроде таких. Но всё упирается в абсолютнейшую несовместимость зон ответственности. Всегда на практике оказывается невозможно заменить скриптом человеческий фактор. Потому что человек должен ПОНИМАТЬ что он делает, и чего это будет стоить.

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

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

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

К чему веду: всё что нормально делается — делается на бэкенде. А всё что делается на фронте — делается исключительно теми людьми, которые пишут корпоративный фронт. А ты работаешь с их бекендами, и крайне редко — пишешь бекенд под их фронт. И совсем никогда — не берись писать фронт, тем более в связи с их беком. Если хотят — пусть аутсорсят, ты дай API и всё, притом чётко по ТЗ. В противном случае ты никогда не сделаешь как они хотят — за вменяемое время, тем более за вменяемые деньги.

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

А выливка звонков — это задача примитивная до нельзя. Особенно если ты захватываешь канальные переменные и они оказываются в этом CDR или любой другой таблице/базе. Открываешь обычную view на SQL с новым пользователем без лишних полномочий — и пускай её дрочат прям таки в онлайне. Если количество звонков пойдёт на миллионы, тогда уже будешь что-то оптимизировать.

Мы немного о разных вещах говорим. Говна и палок много, но это в основном следствие того, что легаси там частично страшнее энтерпрайза. Ну и у программистов и связистов разные школы все-таки. Я долго пытался понять нечеловеческую логику Нортела, но после было странно смотреть на те же системы типа Asterisk.
А про понимание того, что человек хочет.... Я скажу так. За годы опыта я уже сам лучше знаю, что хочет человек. И смогу ему это донести, что немаловажно. И опять же, задачи бывают разные. Я не говорю, что хочу писать системы отчетности уровня Cisco Call Manager.
С авторизацией справятся. Честно. В инет она смотреть на радость кулхацкерам обычно не будет. Ну и безопасность — чуть другой вопрос.
Я понимаю, что программирование на Джаве заставляет думать, что все вокруг энтерпрайз. Нет. И в SMB, и в SOHO есть запросы и есть деньги на их реализацию.
Ну и да, можно, конечно, секретарше дать тот самый phpMyAdmin, но это все-таки не то.
«дай API — пусть аутсорсят» — прекрасно, но опять же, не надо думать, что везде летает Энтерпрайз со Споком. Дайте пожить и средне/малому бизнесу.
PS: А таких Ев я для развлечения на коленке писал, правда, без отчетности и красивого сайтика.
PPS: Трехзвенная цепь — это про что?

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

А задач связи вне энетрпрайза, пусть даже маленького — не встречал ни одной.

А таких ев точно не писал ни одной. Потому что там на полдня программирования вменяемого диалплана, и вечность — чтобы этот диалплан действительно работал так чтобы реализовать забажанку, да с параметризацией, и чтобы параметризация была понятна SMMщице, и чтобы не превратиться в спамера. Я же говорю, голосовая связь имеет встроенную проблему — РАЗДРАЖАЕТ ЛЮДЕЙ. В любой реализации. А эти люди будут ипать мозги угадай кому.

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

Если только ты не хочешь создать свою компанию, которая собственно и создаст прослойку, делающую нужный сервис под заказ и с последующим обслуживанием. То есть делать свою Зингайю с блек-джеком и покером. Тяжёлое это дело — с человеческим фактором работать. И вдвойне тяжёлое — работать с браузерами и прочими «тонкими» клиентами, которые имеют «особенностей» больше операционки. Добавь к этому работу с «дизайнерами» которые «я художнег я так вижу», и маркетологами которые собачат чужие скрипты куда ни попадя не понимая что делает eval в JavaScript [правильный ответ — всё что захочет]. ИЧСХ, это дерьмо — вечное, нельзя раз сделать и чтоб хотя бы год пахало.

Так а никто и не будет фронт напрямую пускать в софт связи. API есть всегда. В каком-то смысле оба этих фреймворка делятся на фронт (темплейты) и бэк (url-router) если грубо.
Если задач не встречали — не значит, что их нет.
И еще раз. У многих контор вполне ограниченный набор задач, которые они решают. Этим достаточно все настроить и они про тебя забудут на полгода-год. Это же будет касаться и системы отчета. Не весь мир живет в энтерпрайзе.
А с человеческим фактором работать приятно. Тут ключевое — выбирать людей, что нереально в энтерпрайзе, но вполне — в SMB/SOHO и фрилансе.

Тогда несколько удивляет выбор именно Django. Клиенты бы явно предпочли те платформы, на которых уже поднят бэкенд.

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

Клиенты предпочитают готовое решение, а не разбираться в тонкостях как и на чем оно построено. Им что Django, что Spring, что JQuery — просто набор слов. А вот графички и таблички — уже что-то.
Я не пытаюсь решить задачу интеграции любой клиентской системы CRM/ERP с телефонией, это отдельная задача.
Можете мне не верить, но задачки отчетности и графиков вполне могут соседствовать с CRM на гугльдоках. И какой тогда у людей бэк? И таких клиентов не просто много, а очень много. И не только в Украине.

Мне ли не верить, до сих пор вкус собаки на зубах. Но тогда это JavaScript c JSON-бэкендом, вряд ли понадобиться что-то большее. А JSON из базы данных сделать может любой язык, вероятно даже сама база. Особенно если это NoSQL.

Отчётность — это опять же база данных + JS. Основные действия ты творишь на стороне клиента. И вероятнее всего, если ты не знаешь что будет на клиентской стороне — это либо чистый JS [мерзость страшная] или свои iFrame полностью на своём бэкенде.

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

www.codementor.io — не пробували?

О. Навіть не чув про таке. Дякую.

Уж послал, так послал )

Підписатись на коментарі