Программирование

Сайты это программы будущего Когда первые сайты появились, они выглядели сильно иначе, да и возможностей было куда меньше. Производительность тех компьютеров была в разы ниже. Ещё много лет назад я говорил, что в будущем, большинство программ заменят сайты. Их быстро и удобно создавать, есть большое количество информации в интернете по созданию и продвижению сайтов разного масштаба, а чтобы пользователю попробовать ваше творение нужно просто перейти по ссылке. Ну и не стоит забывать про мультиплатформенность. Люди смогут воспользоваться вашей страничкой в интернете на любом устройстве, на котором установлен браузер. Дело в том, что возможности сайтов почти не ограничены, у них есть хранилище, где можно сохранять какую-либо информацию. Есть возможности для отправки уведомлений, сообщать свою геопозицию. Можно отрисовывать полноценную графику. Вспомните количество браузерных игр. Их действительно много, на любой вкус и цвет. Есть уже сайты где можно полноценно отредактировать свою фотографию, вырезать фон, смонтировать видео. Вместо программы телеграмм, можно полноценно пользоваться его браузерной версией. Чтобы посмотреть видео (YouTube), послушать музыку (Spotify), хранить фотографии (Google Photos), в наше время вам достаточно только браузера. Но у сайтов есть один минус, это их открытость. По сути, весь сайт загружается в открытом виде при посещении. Эффективную защиту написать сложно (но можно попытаться), а значит и как-то монетизировать проект тоже будет тяжелей. Но выход есть, можно выполнять операции на сервере, а на стороне пользователя только показывать интерфейс (визуал). По этому, мы будем встречать больше новых, продвинутых сайтов с крутым функционалом. У каждой шаурмичной есть уже свой сайт в интернете, и выглядит он вполне неплохо. За сайтами будущее!

Скайнет уже не за горами! Многие думают что искусственный интеллект и нейронные сети это что-то сложное и непонятное, отчасти так оно и есть. Все популярные нейро-сервисы по типу гугл-переводчика и ChatGPT довольно сложно устроены и такое вам вряд ли удастся повторить в одиночку. Да и зачем? А вот простые нейросети это совсем не сложно, как бы странно это не звучало. Такую нейросеть можно написать всего за несколько минут под вашу задачу. Вообще, они нужны тогда, когда обычный линейный подход дает неточный результат, когда данных очень много и непонятно по каким данным это все структурировать. Допустим, у меня есть статистика сообщений в чате для всех пользователей, кого-то я забанил, потому что они спамили, кого-то нет. Но как переложить эту работу на программу? Какие требования нужно разработать, чтобы понять что одного человека нужно исключить из беседы, а другого нет? Я могу вводить какие-то удобные мне правила, например если человек за 1 минуту оправил 10 сообщений, значит о спамер. Но не всегда это так, все зависит ещё от большого количества факторов, например: размер сообщения, наличие там ссылки, пересланное это сообщение или нет и много чего ещё... Это все надо как то учитывать... Нейросеть как раз существует для решения подобных задач. Мы "скармливаем" или же показываем нейросети статистику по пользователям и говорим кто хороший, а кто плохой. Нейросеть ищет взаимосвязи между этими данными и так сказать тренируется, калибруя различные показатели чтобы повысить свою точность. Когда точность будет нас устраивать, нейросеть останавливает обучение. Теперь мы можем просто загрузить статистику пользователя нашего чата нейросети и нейросеть скажет что с ним нужно сделать, основываясь на тех данных, которые мы делали раньше. Тем самым, нам удалось автоматизировать этот довольно сложный процесс, требующий анализа каждого индивида, но теперь это все делает робот за считанные секунды (а то и миллисекунды). Это конечно самый простой пример применения нейросети. Обычная сортировка, отличить А от Б. Но все это ограничивается только вашей фантазией. Хорошего дня! 😉

Я же обещал рассказать про запросы чуть подробнее? Пришло время. Http запросы делятся на методы, самые основные это GET и POST. Это прям классика. GET запрос это по сути любое ваше посещение сайта. Get с английского переводится как получить. Вы переходите по ссылке и получаете какие-либо данные. Чтобы что-то получить, вы должны передать серверу какую-то информацию через параметры. Я уверен, что хоть раз в жизни вы могли их видеть в ссылках. Начало GET параметра в ссылке это знак вопроса (?), дальше идет название параметра (например name) и значение (например value), если нам нужен ещё один параметр, в качестве разделения используется (&), а дальше снова название параметра и значение. Допустим, что наш сайт принимает GET параметры по адресу https://site.com/info, тогда GET запрос будет выглядеть так: https://site.com/info?name=value&name2=value2. Что же мы такое сделали? Мы передали нашему сайту 2 значения, которые он получит после нашего перехода по ссылке. Он может обратиться к значению name и получить value. В жизни же программы и сайты передают большое количество информации в этих параметрах и это удобно, потому что ссылкой можно поделиться и другой человек тоже может отправить эти параметры. Но есть так же и POST запросы. Как вы могли догадаться, их параметров не видно в адресной строке. И поделиться ими не получится. Работают они так же, только все данные передаются в теле запроса. И в отличии от GET запроса передавать можно не только текст, но и файлы. Например, принять картинку от пользователя. Если просто так вам воссоздать его будет очень тяжело, то с технической стороны все довольно просто. В атрибуте формы в HTML можно указать метод запроса, через который данные будут отправлены на сервер. А внутри самой формы можно добавить поля, которые будут превращены в параметры после заполнения формы. Так что, GET запросы это просто ссылки, где все параметры у вас на виду, даже если их нет, то это тоже GET запрос, просто без параметров. POST запросы стоит использовать когда вы передаете много информации, файл, или чувствительную информацию, а GET запросы для вашего API или же когда пользователю можно дать возможность поделиться этой ссылкой с другими. Ну или представим ситуацию, мы отправили пользователю письмо на почту, где содержится ссылка для подтверждения его аккаунта. В ссылке мы должны как-то оставить код, по которому сервер поймет какой аккаунт нужно подтвердить. Через POST запрос нам не получится донести до сервера этот код, потому что в письме мы можем оставить только ссылку, остается GET запрос, в одном из параметров мы и укажем этот код. Пользователь перейдет по ссылке, мы прочитаем этот код и подтвердим его аккаунт. Как то так, друзья. Хорошего дня 😉

JWT токен или как пользователь сам хранит инфу о себе Для того чтобы понять, что пользователь авторизован, используют сессии. Это упрощенный способ идентификации пользователя, которая создается после успешной авторизации. Кто-то то хранит все в базе, кто то в сессии PHP, а кто то в JWT токенах. Принцип прост, мы даем пользователю набор символов или же ключ или токен (не суть), которые он передает при каждом действии на сайте или приложении. Так мы понимаем что он это он, и если у него нет прав на определенное действие, ему будет возвращена ошибка. Но если с хранением данных пользователя на сервере все понятно. Когда пользователь отправляет нам этот ключ, мы подтягиваем с сервера базовую инфу о нем, его ID в системе например, или логин. И дальше уже работаем с этим. То как можно доверить пользователю хранить информацию о том, какой у него ID или логин. Можно же представиться любым пользователем нашего проекта, даже администратором... Не все так просто. Я уже писал о хешах выше. Они тут очень помогают. На сервере создается секретная фраза, которая соединяется с информацией о пользователе, и все это хешируется. В итоге получается набор символов, который можно отдать пользователю. Пользователь при каждом действии отравляет токен нам. А мы понимаем что он это он, потому что внутри зашифрована информация о нем. Мы проверяем эту информацию с помощью хеша и секретной фразы. То есть всю его информацию мы снова берем и соединяем с секретной фразой, хешируем и если хеши совпадают, значит пользователь действительно тот за кого себя выдает. Он не сможет подделать сессию потому что у него нет секретной фразы. Так вот и работают JWT токены, их используют многие крупнейшие компании от ВК до Яндекса. Это может сэкономить мощность сервера на поиски базовой информации о пользователе. Вы тоже можете брать на вооружение такой способ идентификации зарегистрированного пользователя в своих проектах, главное нигде не палить секретную фразу и делать её посложнее. Всем хорошего дня!