На счет iframe смысл был в том, что это полностью ваше приложение, а сайт - это мое приложение. Пользователь, зайдя ко мне может это отличить. Для меня прозрачность в том, что ваш сервис мне не навредит.
> Анализ сообщений задача исключительно клиентская.
да, да расскажите это internal модераторам любого популярного форума.
> Не хотите чтобы пользователь увидел что–то плохое, все в ваших руках.
Ок, еще раз, какой смысл в вашем сервисе? Если транспортировка и pub/sub - nodejs+redis в полной мере решают задачу. Если что-то еще, что я упустил - укажите.
Да все просто: ваш сервис должен в полной мере реализовывать прозрачную переписку в отдельном брендированном iframe.
Ваши клиенты должны быть оповещены через API о каждом из сообщений с возможностью верификации.
Например один пользователь другого на*** послал: вы должны сказать клиенту вот есть такой пользователь, он отправил другому сообщение, но это сообщение содержит какой-то стремный контент, вы даете апрув на передачу другому пользователю?
При этом для каждого пользователя (в случае http) текст шифруется сесионным ключом.
Так же уберите тему с пожертвованиями с сайта. Абсолютная часть подобных программ (не обязательно IT) - чистой воды обман
Я не спорю, что присутствует)) Но есть нюанс, что мне в js очень не понравился: send_message, вы в начале метода не делаете жесткую проверку типа msg. В случае, если передать туда строку - шифрование не будет выполняться, но строка отправится.
В chat.js вы этим пользуетесь, строка 57
В случае, если ключ хранится на клиенте - получаем довольно интересную штуку (конечно если я праивльно понял как работает ваш сервис):
У 1-го И у 2-го клиента должны быть одни и те же ключи для шифровки/дешифровки, на сервер - тоже.
Что вам мешает 1 раз зайти на мой сайт и узнать этот ключ, домен у вас есть?)) Как результат - это только видимость защиты.
Я знаю, что не взламываемых систем не бывает, цель любой защиты - сделать ее взлом не выгодным.
В случае с вашим сервисом - защита только на уровне доверия.
> Есть нюанс: объективно программирование - скучная, сложная, монотонная, ответственная, созидательная работа.
Но вы не найдете ни одного Мидла/Синьйора, которому она не нравится
@wkololo_4ever
@Inv3go
Есть нюанс: объективно программирование - скучная, сложная, монотонная, ответственная, созидательная работа. Что бы не потерять "запал" - нужно сначала поставить цель, которая будет вдохновлять.
Даже в случае, если первым ЯП будет JS - это вовсе не значит, что все будет легко, и в шоколаде. Если попытаться сделать авторизацию (ввод логина и пароля с их проверкой) - вдруг окажется, что браузер этого не умеет. И что бы это сделать нужно знать HTTP, что такое web сервер, что такое база данных и NodeJS, а там далеко не все так просто. Многие фронтендщики, считающие, что хорошо знают JS в том же NodeJS теряются и понимают, что таки не знают.
Я рекомендовал С потому, что он даст понимание, как в принципе работает компьютер, что такое память, что такое процессорное время + он НЕ требует знать сразу стек технологий, в отличии от того же JS. Браузерный JS без HTML/CSS, знания DOM, понимания событийной модели работы - это абсолютно бесполезная хрень, годящаяся разве что для Hello World. У NodeJS (серверный JS) - уровень вхождения на порядок выше, утечки памяти в принципе ищутся как подземные воды у лозоходцев.
Вы хотите обучить системного программиста, или web-программиста?))
Если web - то, первое, с чего надо начинать - это HTML + CSS, потом PHP + MySQL, и уже потом JS + NodeJS.
То, что в школах и универах учат сортировкам и как бы все - это только подтверждает, что утверждение "с-ма образования пост-СНГ - превратилась в говнище". Но это вовсе не значит, что на C только сортировки пишут.
Из задач можете рассмотреть например:
* сделать обертку для вызова gocr, и распознавать чеки (если именно через консоль делать - там ничего сложного)
* сделать микро сайт www.fastcgi.com/devkit/doc/fastcgi-prog-guide/ch2c.htm
olexandr7
Друг как то историю рассказывал: на собесе про кучу всего поговорили, а потом пошли вопросы по сигнатурам методов, например модификаторы у функции sprintf...
У меня тоже ситуация была: про подавление нагрузки поговорили, индексы на аминокислоты разложили, сервера кэшей/очередей тоже проговорили. Интервьюер: ок, а теперь к практике, что произойдет:
$a = 5 + '5abc' + 'abc5';
Я: посмотрю блейм скрипта с целью узнать кто автор, дальше с ним поговорю с целью понять, что такого может в жизни произойти, что бы он позволил себе такое написать.
И: ну, тут задача на приведение типов
Я: да я понимаю, что 10, вы в реальном коде хотя бы раз подобное видели?
И: нет..
Я: я тоже..
Не все зависит от рекрутера)) Тех. специалист может быть хреновым интервьюером.
composer локально без sudo... Это phar архив, sudo может понадобится только когда хотите его глобальным по системе сделать, например скопировав в /usr/local/bin
> есть ли способ установить так же npm?
Я запутался, вы что хотите сделать? Локально установить npm и composer? Если да - то читайте оф. гайды по установке, права суперпользователя таки потребуются.
Ну как сказать, то что пишут в вакансиях, не всегда соответствует действительности. Обращайте внимание на уровень, который указывается в вакансии. Senior web-мастер вы вряд ли найдете. Для бекендщика часто пишут что-то в стиле "Strong knowledge: HTML5, CSS, JavaScript", в частности на текущую должность тоже в вакансии что-то подобное было, но за пол года я написал штука 30 HTML тегов...
На счет убегать от web - зря вы так, все движется в web))
beduin01
Если ты хочешь делать сайты - даже не думай, что одним языком отделаешься))
IncorrecTSW
> Но он прост как 3 копейки и на нем накидать прототип или мелкий сервис вообще без проблем.
Нода далеко не под весь веб - хоршая идея. Утчеки памяти можно определяется примерно так же как подземные воды у лозоходцев. Синхронные вещи на ней - тоже на самая лучшая идея. В случае HL обязательно придется увеличивать количество потоков для реализации асинхронщины, по умолчанию их 4. Под прототипы - php))
beduin01
> Dart конвертированный в JS работает быстрее, чем нативный код на JS
Знавал я доного порня, который утверждал, что программы на транслируемых языках быстрее, чем на языках в которые они транслируются, его потом в дурку забрали ясное дело
> ну учитывая, что кучу сайтов на Ruby и PHP пишут видимо математические вычисления в Вебе не так уж нужны...
Мат. операции используются постоянно, обычно не сложные, но все же + к тому как правило основное время - это ожидание данных от БД, или внешних сервисов. В случае с PHP - вообще пичаль, это state-less язык.
> а почему тогда NodeJS все так хвалят?
Хипстеры, что с них взять))
Есть планы записать несколько cool story + написать небольшой проект и по нему тоже несколько видео, правда web - будет как частный случай использования.
Go под web далеко не всегда имеет смысл использовать. Например те же бложики на go - с пушки по воробьям. Но под state системы с асинхронщиной и требования к производительности/памяти - вполне ок.
Если есть какие-то предложения по темам - напишите
Возможно я не совсем правильно выразился.
Задача "сделать биллинговую систему" - это абстракция высшего уровня, без привязки к конкретному проекту (или бизнес процессу) она может значить что угодно.
> У меня нету ТЗ , есть задача просто затратив меньше усилий автоматизировать больше процессов.
Дык описывайте, какие процессы вы хотите автоматизировать и что конкретно у вас не получается.
CyrusHarding
Вы сделали не правильные выводы по прошлым вопросам.
На них не отвечают потому, что:
1. Многабуков. Не пишите большие вопросы,
2. Вопрос-агрегатор. Не пишите в одном вопросе 1),2),...10)... один вопрос - один контекст.
3. Не спрашивайте "как сделать ...?", "или на каком движке сделать ...?". Штука, которую вы хотите сделать должна быть хорошо описана в ТЗ, и только на основании ТЗ стоит выбирать фреймворк. То, что вы можете получить тут как ответ - это "юзай А", "нет, юзай Б", "юзай В"... Но ничто не будет правильным ответом))
Вместо подключения по сокету unix:///tmp/mysql.sock подключайтесь по стандартному порту 3306 (конечно если у хостера он не кастомный)