Вся проблема нашего общества в том что есть много индивидов которые оценивают «народ» и других людей, вместо того чтобы что-то взять и сделать. Развитие рунета зависит от наших действий а не рыдания постами и комментариями в виду того какие мы все плохие. Как по мне твиттер пережиток прошлого ввиду недостаточного функционала. И разница между твиттером, фейсбуком и контактом именно в функционале в общем, а не в наличии видео и прочего контента. Функционал позволяет все это хранить и использовать. Это мое мнение. Linkedln известен и у нас тем кому оно надо, а так же имеем МойКруг и прочие проф.сети. ИМХО.
П.С. Автор, вам как-будто промыли мозги американизмом и европеизмом, что там вся цивилизация, а тут село. Либо вы пытаетесь всем промыть мозги об этом, специально делая только во вред. ИМХО.
По-моему MOVE нарушает принцип KISS. MVC эталонная модель и в реальных проектах могут быть отклонения специфичные для некоторого функционала, но не вижу смысла разделять трехзвенную логику позволяющую делать тоже самое на четырехзвенную. Чем больше компонентов — тем больше кода и файлов, а значит выше сложность. Зачем плодить сложность на пустом месте? ИМХО.
Тоже верно что касательно работы. Но чем больше людей двигают прогресс сейчас, тем быстрее наступит будущее ;-) А его хочеться посмотреть еще в этой жизни ))
Рано или поздно, а скорее рано… многие забивают на самообучение так как у них уже не вышло, а еще они пробовать уже не хотят. Важно упорство и стремление, мотивация в собственном развитии и желание сделать что-то новое/лучше/полезнее. Вот при таком раскладе работа найдет сама.
Действительно достаточно большая часть весьма напоминает Freelancer, выпущенную в далеком 2003 =) графика и возможности на тот момент впечатляли =) На несколько порядков меньше игра напоминает КР или Homeworld, вот именно Freelancer оно и есть. Видать весомая часть была кем-то оттуда сильно позаимствована.
Несколько ранее был добавлен пункт 0, подсказанный пользователями. В нем же уточнялось что во всех пунктах ниже md5 используется только как пример. Но за ссылку и доп. инфу спасибо =) принял к сведению.
Ну одна из идей самой статьи показать человеку какой-то пробел в знаниях, если он что-то пропустил. )) Для себя я уже отметил достаточно много пробелов согласно комментариев. Я понимаю что многие отнесутся к попытке быть хорошим админом и одновременно хорошим программистом скептически, но думаю что это не невозможно. =)
п. 22. Согласен. Пункт и предпологает рассмотрение методов достижения целостности с помощью ключей где это возможно или же продуманных алгоритмов сохранения целостности в случае невозможности использования ключей. Основная суть не пропустить как-раз таки накопление муссора.=)
п. 25 может разрозить холивар если будет указывать на что-то конкретное, всегда найдутся противники для любой СуБД, по этому надеюсь лишь что пользователи на свое рассуждение рассмотрят те или иные реализации со всеми вытекающими в конкретных статьях по каждой из них сами. =) Это материал далеко не одной статьи. Но себе на заметку взял.
Спасибо. Обо всем кратко и точно =) Внес ваши правки в текст. =) Так собственно материал и оттачивается до эталонного состояния, в котором уже сейчас есть действительно много полезного.
Спасибо, принял к сведению. Не могу отнести себя к опытным, уже очевидно что проигрываю по части опыта Вам и многим другим, но все же мне лично иногда не хватало именно обширных статей, которые указывали бы куда именно кинуть свой взгляд по ширине всего вопроса и что я мог пропустить. Данный пост не панацея от всех болезней, в нем и ожидалось получить множество поправок, от действительно опытных пользователей. Теперь же, те кто будут видеть данный пост увидят то чего может еще не видели в тексте и в комментариях, на которые есть посыл в посте, увидят и то на что реально стоит обратить внимание. Возможно повторюсь, что те для кого многое здесь очевидно и неверно, уже подзабыли как сами достигали того уровнять что у них есть сейчас. У многих этот путь еще впереди.
sleep тоже неверное решение, ибо у вас будут просто так простаивать потоки c PHP интерпретатором, а это потребляет много памяти, кстати это ещё один вектор для DOS атаки, хехе, я ваш хостинг с такой защитой через прокси серверы легко в даун отправлю. Почитайте про limit_req_zone для nginx или mod_evasive для apache.
Все всегда легко если уже знаешь это. Чем больше знаешь, тем больше все очевидно. И КОпетан находиться всегда рядом. =)
п.4 предлагает генерировать пароль и отправлять на почту вместо ссылки с подтверждением email. Войдя пользователь сам может сменить свой пароль на тот который захочет в настройках профиля.
п.7. Говорит вконце о наличии библиотек, которые уже занимаются чисткой и от XSS и закрытием не закрытых тегов, прочее.
п.8. Согласен, достаточно размытый получился. Говориться о том что:
1) Красивее ссылка, ее проще скопировать и отправить кому-то другому.
2) Поисковики хоть и умеют в некоторой степени отбрасывать данные из ссылки, выделяя саму ссылку, но все же ссылка становиться раздутой.
3) Видимость отправляемых данных. Большинству пользователей это ни к чему вообще, да и пользы думаю в этом мало, если и есть какая-то.
П.С. Учитывая Ваш весьма высокий уровень судя по критике, добавьте пару правил от себя =) Было бы для меня и других хорошей подсказкой. =)
Да, чем больше параноя, тем больше мощностей на нее уходит. Да и с учетом что чем больше кода, тем больше вероятность ошибки в нем, легче тоже не особо становиться =) Баланс между безопасностью и производительностью. =)
В статье сводиться все к тому что отправляется ключ для смены пароля, который нужно ввести уже в следующей форме. Если пользователь игнорирует сообщение, пароль остаеться тем же. Но точно знает уже что была попытка сменить его пароль. =)
Свалились уже? O_o а ведь хотел сайт посмотреть зайти =)
П.С. Автор, вам как-будто промыли мозги американизмом и европеизмом, что там вся цивилизация, а тут село. Либо вы пытаетесь всем промыть мозги об этом, специально делая только во вред. ИМХО.
Спасибо. Упомянул =)
п. 22. Согласен. Пункт и предпологает рассмотрение методов достижения целостности с помощью ключей где это возможно или же продуманных алгоритмов сохранения целостности в случае невозможности использования ключей. Основная суть не пропустить как-раз таки накопление муссора.=)
п. 25 может разрозить холивар если будет указывать на что-то конкретное, всегда найдутся противники для любой СуБД, по этому надеюсь лишь что пользователи на свое рассуждение рассмотрят те или иные реализации со всеми вытекающими в конкретных статьях по каждой из них сами. =) Это материал далеко не одной статьи. Но себе на заметку взял.
А за это спасибо =)
п.4 предлагает генерировать пароль и отправлять на почту вместо ссылки с подтверждением email. Войдя пользователь сам может сменить свой пароль на тот который захочет в настройках профиля.
п.7. Говорит вконце о наличии библиотек, которые уже занимаются чисткой и от XSS и закрытием не закрытых тегов, прочее.
п.8. Согласен, достаточно размытый получился. Говориться о том что:
1) Красивее ссылка, ее проще скопировать и отправить кому-то другому.
2) Поисковики хоть и умеют в некоторой степени отбрасывать данные из ссылки, выделяя саму ссылку, но все же ссылка становиться раздутой.
3) Видимость отправляемых данных. Большинству пользователей это ни к чему вообще, да и пользы думаю в этом мало, если и есть какая-то.
П.С. Учитывая Ваш весьма высокий уровень судя по критике, добавьте пару правил от себя =) Было бы для меня и других хорошей подсказкой. =)