Как стать автором
Обновить
52
0
Alexander Russkiy @Kolonist

Разработчик

Отправить сообщение
В чисто академических целях можно вообще не отлавливать исключительные ситуации. В мануале для новичков лучше просто поубирать "@" и «or die()». Так или иначе, ни в коем случае нельзя учить этим пользоваться, надо сразу приучать к дисциплине и хорошему коду.
А можно код отформатировать, чтобы с отступами был? А еще избавиться, наконец, от "@" и «or die()».
«Нарисовать» сто тысяч документов с видеозаписями, сканами, таблицами и графиками… Это ж какой талант иметь надо, а времени сколько…
А ничего и не надо гарантировать. Власти все равно в проигрыше. Будут молчать — все будут думать, что сказать нечего. Будут отрицать подлинность — все решат, что отговорки. Попытаются закрыть сайт — тем более народ посчитает опубликованную информацию подлинной.

Да и смысл всего этого, ИМХО, в том, чтобы поднять шум, сформировать общественное мнение, а не открыть истину.
Кстати, не удивлюсь, если к WikiLeaks приложили руку представители неких конкурирующих с ЦРУ развед-органов.
Да те же ФСБ-шники… А сейчас подняли этот шум только для того, чтобы от себя подозрение отвести — мол, видите, про нас там тоже пишут, значит это не мы.
У меня наоборот. Без прокси, но по DNS я в США.
А Калининград, оказывается, в Азии о_О
В чем же разница между двумя товарами, один из которых может быть возвращен или обменян, а второй — нет?

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

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

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

Просто в Вашем случае даже непонятно, что именно Вы собираетесь предъявлять. Если это СМС-сообщение на телефоне, так проверить подлинность можно — экспертиза + логи оператора.

Мне известны случаи, когда запечатленный в системе видеонаблюдения злоумышленник «в тупую» отрицал свою личность на записи и его не могли привлечь к ответственности.

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

Насчет доказательств ничего сказать не могу, так как из описания абсолютно ничего не понятно.
Упомянутый border-radius, равно как и некоторые другие фичи HTML 5 и CSS 3 нужны для красоты, т.е. на доступность информации, размещенной на сайте, не влияют.
Так и не вижу в этом проблемы. Те, у кого современный браузер, будут смотреть на красивый сайт. Ну а те, у кого все еще IE, будут смотреть на квадратные углы и т.п. Но информацию на сайте получат и те, и другие.
Мозилла пишет, что дело не в безопасности. Документы с query string взятые из кеша могут быть бесполезными к тому времени, как мы к ним обратимся. Т.е. Мозилла запретила прелоад подобных URL с целью снизить нагрузку на сервера.

Вот комментарий с их сайта:
This is done because such URLs often result in documents that cannot be reused out of the browser's cache, so prefetching them often has little benefit. We found that some existing sites utilize the tag with URLs containing query strings to reference the next document in a series of documents. Bugzilla is an example of such a site that does this, and it turns out that the Bugzilla bug reports are not cachable, so prefetching these URLs would nearly double the load on poor Bugzilla! It's easy to imagine other sites being designed like Bugzilla, so we explicitly do not prefetch URLs with query strings.
Ссылка не сохранилась, но сегодня я как раз читал статью на каком-то новостном сайте про то, что о разработчике ОС нового поколения написали даже на хабрахабре.
А какая разница, как к Вам придет число, как «1000» или как 1000? Чем первое не подойдет? Тем более, если Вы точно будите знать, что пришло именно число, а не, скажем, "` OR 1=1".

В PHP вся прелесть в том и заключается, что можно писать как 2 + 2, так и «2» + 2, и «2» + «2» — результат будет одинаковым. Да, привыкнув к языкам со строгой типизацией, как C++ или Pascal, такой подход может казаться странным и нелогичным, и тем не менее, это PHP. Хотите строгую типизацию — используйте другой язык.

Однако, с Вами я все же соглашусь в том плане, что при объявлении int-аргумента, строки, которые не представляют собой числа, т.е. например «9ttt571», скорее всего должны вызывать хотя бы warning.
Одной из основополагающих особенностей PHP всегда было неявное преобразование скалярных типов. Т.е. строки, числа, логические значения всегда могли быть преобразованы друг в друга. При этом, от отсутствия возможностей явного преобразования PHP никогда не страдал — всегда можно проверить какой тип имеет переменная, так же всегда можно явно привести переменную к нужному типу.

Для PHP-программиста, вообще не должно быть разницы, как именно в его функцию передается, например, числовое значение: 8421 или «8421». При этом, ведь всегда можно проверить, что «8421», действительно, представляет собой число, а не, скажем, строку «842l».

Я за то, чтобы была возможность указывать ожидаемый тип, но чтобы это был тип, к которому должны быть преобразованы аргументы функции. Разумеется, это должна быть именно возможность, а не обязанность. Например, если я пишу:

function myFunc(string $x1, int $x2, $x3) {}

то это должно означать, что в качестве $x1 может выступать как «just string», так и 8421, при этом, 8421 должно быть автоматически преобразовано в «8421». В качестве $x2 может выступать не только 8421, но и «8421», и «8421str», но строки должны быть автоматически преобразованы в int по правилам PHP.
Честно говоря, не знаю, в чем проблема. У меня самого FF 3.6.3 в качестве основного, так что в нем-то я в первую очередь проверяю. А вообще, работать должно во всех современных браузерах.

Видимо, все же, что-то блокирует. Либо что-то отключено.
Браузер системным требованиям соответствует? Javascript включен? AdBlock не блокирует? Noscript не запрещает? Давайте в контакте, в каментах к приложению, или через личку, чтобы тут не засорять.
Нет, зачем. Есть специальное API, данные получаю через JSONP. Все работает исключительно на стороне клиента. Единственное, отправка в твиттер происходит через мой сервер, если пароль доверите.
Я на будущее уже запланировал. Постепенно буду расширять функционал приложения, доводя до функционала самого Твиттера, естественно, со спецификой контакта.
Мне нужно чтобы последнее сообщение из твитера стало статусом вконтакте.

Вот именно это я и сделал.
Сделал через API. Не думаю, что заблокируют, смысл? Им же наоборот выгодны популярные приложения.

И про популярность Вы тоже, ИМХО, преувеличили. У меня уже давно приложение для Твиттера готово, но оно почти никому не нужно. А я еще удивлялся, почему до меня такое никто не сделал. Видимо, просто не та аудитория…

Информация

В рейтинге
6 181-й
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Дата рождения
Зарегистрирован
Активность

Специализация

Бэкенд разработчик
Средний
C#
Многопоточность
Объектно-ориентированное проектирование
Разработка программного обеспечения
SQL
ASP.NET
PostgreSQL
Linux
MongoDB