Пользуюсь netbeans, но в целом плевать на чём, могу и в ZS, и в phpStorm, на сервере предпочитаю mcedit или ed.
Вот никак не могу понять тех, кто жалуется на тормоза джава платформ. У меня был Duron 800 + 512 RAM, работал с большими проектами. Конечно, при первом сканировании проекта можно было приготовить завтрак, но дальше всё работало с приемлемой скоростью, явных тормозов не было. А на современной машине и вовсе могу одновременно ZS и Netbeans держать. Ресурсы начинают жраться только когда дебажу, да и то, в сравнении с chrome — смешно о них говорить.
Ага, гусиным пером и от руки, как писали лучшие авторы: Пушкин, Толстой, Достоевский. Почему бы не использовать современные возможности для достижения выразительности. Жирный шрифт не только упрощает чтение по горизонтали, но и заостряет внимание на важных с точки зрения деталях, которые могут быть упущены или посчитаны незначительными чтецом. В разговоре мы используем интонацию, паузы, жесты, почему стоит от этого отказаться при печати статей?
Мне кажется, гугл пытается сбить цифру или огнелис пытается увеличить её.
Не думаю, что гугл рискнёт своим будущим ради хрома, ведь BING набрал очень приличные обороты и отдать ему поисковую строку в таком популярном браузере как АА, это потеря большой аудитории, а главное — репутации. Да и с выходом 4-ки фаерфокс сново стал конкурентноспособным. Гугл прошляпил момент, когда можно было похоронить конкурента.
Вспомнилось лебедевское: Идея на минус миллион. www.artlebedev.ru/kovodstvo/sections/161/
Даже в силиконовой долине, проваливается ~90% стартапов с идеями, прошедшими через сито отборов и обдумываний опытными менеджерами.
А питаются они воздухом и молитвой, живут под открытым воздухом? В любом случае кто-то вкладывает деньги, дядя капиталист, друзья, они сами или родители.
Знаете, а ведь такая модель уже была и талантливые художники, музыканты, писатели умирали в нищите, а сейчас за их творения на аукционах платят миллионы, а бедные эксплуатируемые копирайтерами поп певцы за концерт зарабатыват больше, чем Бетховен за свою жизнь.
Если ты такой умный, то почему такой бедный?
Почему Вы считаете что копирайтеры находятся в бедственном положении и не знают что делать? Неужели не видно что они УЖЕ создают и развивают новые каналы распространения: стимы, договоры с ютубе, разные яндекс-гугл мызыка и т.д.
Хуже всего, что видя лишь верхушку айсберга в виде успешный авторов, вы забываете о огромной подводной части и менее успешных авторов или тех, кого копирайтеры содержат до пенсии в надежде, что автор родит шедевр. Забываете о развитии отрасли, о раскрутке, об огромном пути который делает творение по пути от автора к пользователю — работу переводчиков, редакторов, звукозаписывающих студий и т.д. и т.п.
У меня друзья музыканты и я прекрасно вижу сколько в них влаживают денег копирайтеры, в надежде что ребята заиграют или найдут в команду того, кто потянет всех за собой, но всё время этого ожидания ребята работают в минус. И вы хотите забрать у них шанс ради того чтобы вы могли приобрести песенку бритни спирс на десять центов дешевле и на торренте.
Хотелось бы указать ещё на две вредные практики, подмеченные на основании вашего топика:
1. Установка устаревшего программного обеспечения, т.к. fckeditor остался в прошлом и сейчас именует ckeditor.
2. Не читать ПОЛНОСТЬЮ документацию перед использование — чревато.
Да хоть саму сессию можно делать только на куках, если у вас используется несколько разных языков. программирования. Функцию упаковки-распаковки такой сессии можно написать на любом языке.
Сейчас, конечно, проще хранить токен и поместить сессию на сервере в каком-нить memcached, который быстр и клиенты для работы с которым есть на другом языке.
Ну ёлки ж. Я выше писал об этом. Сессии это внутриязыковая сущность, если используешь разные языки, то куки являются более универсальным средством, но приходится их шифровать и проверять целостность. Вот у человека возникла проблема, что нужно учитывать изменения куки посредством js, бывает обратная задача, когда нужно защититься от изменения посредством js. Причём не от злонамеренного, а случайного плагина, который может переписать нужную переменную. Здесь приходит на помощь столь полезный флаг. Мы в своё время писали под обёртку на php4 и не знали о нём, слава богу тогда js-а было мало и мы всё контролировали.
Понятно, что http — протокол без состояния и фактически каждый запрос делается с нуля, а восстановить состояния можно лишь по токену. Но знать о защите «кук» от дурака полезно, даже если с этим сталкивается 1 из тысяч разработчиков.
Ок. Вы правы, но но мне кажется что за демагогией и софистикой вы где-то теряете истинный смысл. Я мог бы продолжить вашу цепочку, вель в реальности куку посылаются не с сервера на сервер, а их отсылает отсылает клиент, коим обычно является браузер. Да и кук никаких нет, это всего-лишь дополнительный заголовок. Да и заголовков нет, это набор байтов, да и байтов нет, это набор битов нулдей и единиц, да и нулей их нет, на самом деле это состояния есть сигнал, нет сигнала, да и сигналов нет, это ток, да и тока нет, это движение электирческих зарядов… Причём каждый термин можно оспорить и представить в нужно виде.
Но если мои куки изменил на клиенте и это может повлиять на логику серверного приложения, то мне плевать как это называется, потому что я знаю как это на сервере проверить и какой оптицей рекомендовать клиенту не трогать присланное сервером.
Вы занимаетесь софистикой и меняете тему обсуждения. Я отвечаю на тезис на который изначально писал коментарий.
>>вы так говорите, будто серверу есть разница каким образом пользователь получил их, через Javascript или нет.
Ответ однозначен. ДА, для сервера может иметь большую разницу каким образом пользователю установлена кука. А то что в серверном языке имеется специальная опция, показывает что это не только моя фантазия.
Чукча — не читатель, Чукча — писатель. Я прекрасно знаю что опцию можно не только обойти, но и она может быть тупо не поддерживаемой клиентом. Но проверить модификацию куки на сервере — не проблема, с помочью полного сравнения с копией на сервере, либо записью чексумы. Выше всё это уже писал и привёл пример из практики, когда проверка кук на серере использовалась.
А в итоге за то что поделился знаниями и опытом, ещё и должен оправдываться. Тьфу.
Выше я показывал пример, просто запрещал доступ к функционалу, если куки изменены. А флаг позволяет защититься от случайных кук на клиенте, которые могут поставить js скрипты.
Если интересно, то этот приём я использовал когда делал сессии в обход стандартного php обработчика сессий, просто хранил данные в шифрованной сессии, а для контроля модификаций дополнительно ставили куку с чексумой. Часть скриптов проекта была на си и perl, так что техника была вынужденной мерой.
я привёл пример каким образом сервер может попросить клиента не трогать куки и код, который позволяет серверу не обрабатывать запрос с модифицированной кукой.
Да, браузер может вовсе не поддерживать данной технологии, да, запрос можно сформировать руками, но я программист или где? Я могу на сервер сайд коде проверить модификацию данных и блочить негодяев.
Скорее всего я ошибся ресурсом, всё никак не привыкну, что на хабре не положено говорить на технические темы, а в комментариях нужно либо лажать автора, либо постить фото Джимми Уэйлса и демотиваторы.
Данный флаг отсылается СЕРВЕРОМ, значит серверу таки " есть разница каким образом пользователь получил их, через Javascript или нет". Ну, а верификацию изменения кук можно делать двумя строчками кода.
if ($_SEESION['cookieCheck'] != $_COOKIE) die('bla bla'); проверяем.
$_SEESION['cookieCheck'] = $_COOKIE; привязываем к сессии. (сессии, как известно могут быть не только на куках)
Вы так говорите, словно уверены что владеете вопросом лучше автора, при этом поленившись даже проверить в гугле свою собственную компетентность. В целях повышения безопасности можно действительно разрешить лишь http only cookie, www.php.net/manual/en/function.setcookie.php
Вот никак не могу понять тех, кто жалуется на тормоза джава платформ. У меня был Duron 800 + 512 RAM, работал с большими проектами. Конечно, при первом сканировании проекта можно было приготовить завтрак, но дальше всё работало с приемлемой скоростью, явных тормозов не было. А на современной машине и вовсе могу одновременно ZS и Netbeans держать. Ресурсы начинают жраться только когда дебажу, да и то, в сравнении с chrome — смешно о них говорить.
Не думаю, что гугл рискнёт своим будущим ради хрома, ведь BING набрал очень приличные обороты и отдать ему поисковую строку в таком популярном браузере как АА, это потеря большой аудитории, а главное — репутации. Да и с выходом 4-ки фаерфокс сново стал конкурентноспособным. Гугл прошляпил момент, когда можно было похоронить конкурента.
www.artlebedev.ru/kovodstvo/sections/161/
Даже в силиконовой долине, проваливается ~90% стартапов с идеями, прошедшими через сито отборов и обдумываний опытными менеджерами.
Знаете, а ведь такая модель уже была и талантливые художники, музыканты, писатели умирали в нищите, а сейчас за их творения на аукционах платят миллионы, а бедные эксплуатируемые копирайтерами поп певцы за концерт зарабатыват больше, чем Бетховен за свою жизнь.
Почему Вы считаете что копирайтеры находятся в бедственном положении и не знают что делать? Неужели не видно что они УЖЕ создают и развивают новые каналы распространения: стимы, договоры с ютубе, разные яндекс-гугл мызыка и т.д.
Хуже всего, что видя лишь верхушку айсберга в виде успешный авторов, вы забываете о огромной подводной части и менее успешных авторов или тех, кого копирайтеры содержат до пенсии в надежде, что автор родит шедевр. Забываете о развитии отрасли, о раскрутке, об огромном пути который делает творение по пути от автора к пользователю — работу переводчиков, редакторов, звукозаписывающих студий и т.д. и т.п.
У меня друзья музыканты и я прекрасно вижу сколько в них влаживают денег копирайтеры, в надежде что ребята заиграют или найдут в команду того, кто потянет всех за собой, но всё время этого ожидания ребята работают в минус. И вы хотите забрать у них шанс ради того чтобы вы могли приобрести песенку бритни спирс на десять центов дешевле и на торренте.
1. Установка устаревшего программного обеспечения, т.к. fckeditor остался в прошлом и сейчас именует ckeditor.
2. Не читать ПОЛНОСТЬЮ документацию перед использование — чревато.
Сейчас, конечно, проще хранить токен и поместить сессию на сервере в каком-нить memcached, который быстр и клиенты для работы с которым есть на другом языке.
Понятно, что http — протокол без состояния и фактически каждый запрос делается с нуля, а восстановить состояния можно лишь по токену. Но знать о защите «кук» от дурака полезно, даже если с этим сталкивается 1 из тысяч разработчиков.
Но если мои куки изменил на клиенте и это может повлиять на логику серверного приложения, то мне плевать как это называется, потому что я знаю как это на сервере проверить и какой оптицей рекомендовать клиенту не трогать присланное сервером.
>>вы так говорите, будто серверу есть разница каким образом пользователь получил их, через Javascript или нет.
Ответ однозначен. ДА, для сервера может иметь большую разницу каким образом пользователю установлена кука. А то что в серверном языке имеется специальная опция, показывает что это не только моя фантазия.
А в итоге за то что поделился знаниями и опытом, ещё и должен оправдываться. Тьфу.
Если интересно, то этот приём я использовал когда делал сессии в обход стандартного php обработчика сессий, просто хранил данные в шифрованной сессии, а для контроля модификаций дополнительно ставили куку с чексумой. Часть скриптов проекта была на си и perl, так что техника была вынужденной мерой.
Да, браузер может вовсе не поддерживать данной технологии, да, запрос можно сформировать руками, но я программист или где? Я могу на сервер сайд коде проверить модификацию данных и блочить негодяев.
if ($_SEESION['cookieCheck'] != $_COOKIE) die('bla bla'); проверяем.
$_SEESION['cookieCheck'] = $_COOKIE; привязываем к сессии. (сессии, как известно могут быть не только на куках)