Проблема в том что её нет.
Контакты
Местоположение
Беларусь, Брестская обл., Брест

Достижения

Все достижения (34)

Наибольший вклад в теги

Все теги (138)

Лучшие ответы пользователя

Все ответы (405)
  • Что нужно знать про ООП?

    gzhegow
    @gzhegow
    aka "ОбнимиБизнесмена"
    А я бы добавил что ООП это украшение кода, а не его суть

    Cейчас есть способы платить Амазону и вообще не писать код, создавая апишки в админке с помощью мышки. Все что будет нужно от ПХП - это делать простые скрипты которые передают данные из точки А в точку Б. Там вообще не нужен будет ООП, потому что не будет понятия "цельный проект" в рамках папки с файлами. Цельный проект это будет куча компьютеров, а на этом конкретно есть передача из А в Б. И тут уже PHPшники посмеются)) Они то готовы к такому

    Увидев, что тебе понравился первый ответ (может ты его и искал?), я попробую пояснить его для тех, кому термины ничего не говорят:

    https://qna.habr.com/q/655113#answer_1431141

    думаю сейчас ты увидишь как набегут великие архитекторы, которые давали тебе советы по этим словам и начнут говорить что то не про это, а это не так и это не здесь. вот это еще одно что надо знать про ООП. Ты никогда не услышишь, что ты прав, потому что термины заменили им мозг, а если им сказать об этом - они объединяются в стаи, чтобы завалить тебя стикерами и унижениями.
    Ответ написан
    19 комментариев
  • Какой php фреймворк наиболее прост в освоении?

    gzhegow
    @gzhegow
    aka "ОбнимиБизнесмена"
    А мне нравится Codeigniter и Yii (самое интересное - первый). Я все никак не подружусь с этими вашими phar'ами, и composer'ами, пока не пойму досконально что там происходит, кроме собственно скачивания модулей с одного сервака в режиме терминала.

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

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

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

    И вроде логично - напиши свой, и, ты думаешь он будет для всех? Нет, ты просто создаешь еще один 101-ый фреймворк.
    Ответ написан
    Комментировать
  • Как передавать пароль от браузера серверу, как его хранить на сервере и проверять корректность?

    gzhegow
    @gzhegow
    aka "ОбнимиБизнесмена"
    В зависимости от степени безопасности.

    Если разбить все это на "по-проще", общий принцип такой:

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

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

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

    Как ты понимаешь, это иллюзия безопасности, а не гарантия.

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

    Вот еще тема, которую василий сказал - шифровать пароль уже на стороне клиента в момент отправки формы яваскриптом. Представьте себя хакером. Вы получили пакеты какого-то чувака, поставили компьютер на расшифровку, подключив десяток видеокарт, расшифровываете пароль, а вместо него видите 64 символьный хеш, ну то есть он прямо от клиента таким вышел. После этого будут маты от того, что теперь массив видюх нужно заставить еще и ключевую фразу из хеша выдрать. Ну то есть еще время декодирования увеличивается. Если загнаться то хеш может быть не просто хешем md5() а например md5 от md5 от развернутой строки прибавленной к md5() прямой строки, прокинутой через побитовый сдвиг на один разряд - ну то есть даже в этом закодировать последовательность действий. При отсутствии https - наиболее надежный способ.

    И потом - программисты Yii не рекомендуют использовать фунцию md5(). Почему? Потому что она быстрая очень. И при переборе пароля массивом видеокарт перебирается он шибко быстро. Поэтому рекомендуют использовать hash функцию, которая для создания хеша использует побольше времени, несколько секунд скажем. При написании синхронной программы (сайта на php, например) - это заставит юзера подождать после регистрации секунды 3-4 лишних, но если загнаться то процесс генерации пароля можно запихнуть в асинхронщину, а пользователю сразу токен выдать, то есть пароль ему сгенерируется чуть позже. Таким образом - за счет более длинной хеш-функции по времени хакеру потребуется куда больше времени - то есть юзеру на прямое создание пароля 5 секунд, а хакеру на перебор нескольких миллионов паролей понадобится несколько лет. Никто ему не заплатит 10 косарей баксов, чтобы сломать ваш долбанный пароль ВКонтакте. Если банковская сфера - опять же как писал выше - хеш от хеша, да развернуть пару раз, да трижды порубить, потом постучать в бубен и все это в хеш еще раз и вуаля - декодирование пароля займет 100 лет.

    Еще значит, При малейшем намеки на несоответствие токена или внезапное изменение - сервак говорит "тю, дядя, давайка пройди второй этап авторизации, а то я не верю, что это реально ты" и просит приложить палец. Или ввести номер, получив СМС. Или вставить ключ-карту синюю (duke nukem hello). Но и тут есть взлом - ключ карту украсть, смс-ку - попросить телефон, приложить палец = отрубить руку, вырвать глаз и тд

    Тут к тебе на помощь приходит https. Https это такая штука, которая в двух словах может быть названа игрой в партизан. На войне играли так - когда радиопереговоры прослушивались, а шифраторов не было - единственным средством защиты - было использовать ошибки в тексте и матерные слова.

    Так и тут - данные отправляемые в виде нулей и единиц. Компьютеры их так же легко перекодируют в пароль, как и закодировали. Чтобы этого не было, придумали ШИФРОВАТЬ строку в одну сторону. У сервака есть трафарет, у пользователя другой трафарет. Сервак шифрует своим, но назад можно расшифровать только пользовательским. Вернее можно и сторонним конечно, но современные компьютеры сделают это за много лет, и потому никто не заморачивается особо, производительность не та.

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

    Так что авторизация - она простая. Вся надежда на шифрование. А сертификат, на котором пол-мира делает бабло - это средство подтверждения того, что компьютер умеет шифровать. Интересно, что он кончается каждый год, как будто в прошлом году компьютер умел шифровать, а в этом вдруг разучился. На деле конечно - просто гоните бабло, иначе покажем красный крестик вместо зеленого замочка, и в гугле понизим, так что гоните бабки. Вот.
    Ответ написан
    1 комментарий
  • Что читать о принципах проектирования и алгоритмах программ на JavaScript?

    gzhegow
    @gzhegow
    aka "ОбнимиБизнесмена"
    Искать мастера.

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

    Послушайте любого тренера в youtube. В большинстве своем они конечно трепачи и бездельники, но в некоторых вещах они сходятся. Например в том, что в Японии был обычай в 18 лет искать Наставника, на Руси был обычай становится Подмастерьем, в любой активно развивающейся стране был обычай что более опытные берут себе на обучение менее опытных из соображений ответственности за свою страну.

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

    Только не начинай сейчас демагогию типа "почему все так не делают". Единственный адекватный ответ будет "может все долбанулись?"

    ps. На это тоже есть объяснение. Деньги лежат в противоположной стороне от созидания, развития и гармонии и ответственности.
    Ответ написан
    3 комментария
  • Можно ли разобраться в ООП в ходе изучения YII2?

    gzhegow
    @gzhegow
    aka "ОбнимиБизнесмена"
    Да как сказать Yii - это ящик с гаечными ключами. Можно ли по ящику понять - зачем ключи? Ну можно, если долго ключи использовать как пишут разработчики - то и поймешь со временем, но есть риск провалится в "делаю как сказали, почему - не знаю".

    Коли про ООП вопрос: разработчикам нужно было писать меньше повторяющегося кода, чтобы не менять одно и то же по 10 раз. Давай по-порядку.

    Представь ассоциативный массив (ключ-значение).
    Теперь представь функцию, любую, пусть будет abs() - число по модулю.
    А теперь забрось эту функцию в свой массив на место какого-нибудь ключа, то есть у тебя как будто получится $array["abs"], где лежит сама функция.

    В чем отличие функции от других данных? Данные ты можешь записать, а можешь считать. А функцию ты еще и выполнить можешь. Таким образом когда ты ее вкинул в массив, у тебя лежит не функция там, а ее заготовка, под выполнение. И ты можешь ее вызвать но уже не как abs(), а как $arr['abs']() - что будет выглядеть одинаково (под капотом все сложнее, но пока забей, оно тебе не надо)

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

    Таким образом ООП это когда ты сначала описываешь внешний вид массива, а потом создаешь вот эти "улучшенные массивы" по описанному виду. Но это только малая часть всего движа.

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

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

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

    Об ООП стоит думать как средство уменьшения числа кода. Если у тебя к примеру два поставщика и два разных файла выгрузки, а действия в них одни и те же - можно прибегнуть к ООП, сделав тип "Поставщик" и описав в нем - что он умеет делать над своими "экземплярами-объектами-улучшенными_массивами" и тд.

    Прежде чем считать, что ты не сможешь без ООП тебе нужно понять, что любая вещь МОЖЕТ быть сделана без ООП. Просто количество путаницы если ты бросишь этот код и вернешься к нему через месяц и уже не помнишь что где и когда - будет больше. Классы создают некую описательную структуру того, что происходит и оттого часто в крупных проектах писать на ООП длиннее дольше и тяжелее, чем без ООП.

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

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

    Я не про то, что типа "еще рано" и тд. Я про то, что есть куча вещей в которое можно отдать время, более интересных и полезных, чем погружаться с башкой в эту муть, которая на деле кроме чувства мнимого превосходства тебе ничего не даст. Просто делай как удобно, и только когда решишь своим массивам задавать поведение - типа "при присвоении ключа в поле `name` автоматически создать поле `code` с таким-то содержимым" - вот тогда реально можешь повкуривать что тут еще можно мутить.
    Ответ написан
    23 комментария

Лучшие вопросы пользователя

Все вопросы (132)