egorinsk

Не нужно. Если в коде не указан копирайт, это еще не значит, что с ним можно делать что угодно.

> сериализация не подходит, так как нужно обезопасить данные.

Значит, надо их шифровать перед записью. Но очевидно, что если программа может их расшифровать, то никто не мешает вытащить из нее алгоритм и ключ расшифровки. То есть, будет защита только от «чайника».

Наверно, для начала стоит изучить синтаксис самого языка, не забыв про всякие вещи типа анонимных классов и Generics. Это быстро, несколько дней-неделю.

Потом стандартную библиотеку: коллекции, ввод-вывод (тут перечислено, что там есть: en.wikipedia.org/wiki/Java_Platform,_Standard_Edition — но все это изучать не надо). Это еще неделя усиленного изучения.

Этого уже может хватить для ваших задач.

Потом можно изучить всякие опции JVM для профайлина и оптимизации.

Если будет интересно, дальше можно смотреть сервлеты, Java Server Pages (или Faces? забыл, в чем разница), фреймворки/библиотеки типа Spring.

Я бы советовал вместо модных непроверенных технологий использовать проверенные — java или C++. Если хранить временные данные в памяти (зачем вам SQL??), то нормальный многоядерный/многигабайтный сервер будет держать соединения тыячами.

Да, я слышал Билайн использует западную технологию перехвата трафика (про которую теоретики с Хабра все время кричали, что Deep Packet Inspection — это сложно, дорого и не окупится и невозможно). Это делается для ускорения загрузки страниц интернета, то есть для вашей же, потребителей, пользы.

Могу, тем не менее, посоветовать пользоваться сайтами, которые используют картинки в формате JPEG. Или использовать Socks/Proxy/VPN.

P.S. А можно увидеть HTTP-заголовки для пережатых картинок?

> Эти пионеры грозятся поставить нечто, под названием «система защиты информации «Аура» на интернет шлюз который работает на линуксе. Гугл подсказывает, что эта программа поддерживает только винду.

Ну что, пожелаем пионерам удачи в этом нелегком деле.

Видимо, стоит банально заглянуть в исходники и посмотреть, из чего и почему формируется такой размер буфера. Опен сурс же.

Вот бы где наверно новый закон об ограничении доступа к информации пригодился бы?

Сомневаюсь, что в энергетике главная проблема — нарисовать схему сети.

Я бы лучше сделал SELECT user_id, MAX(date) FROM stats GROUP BY user_id, а потом бы приджойнил юзеров запросом из приложения вроде SELECT * FROM users WHERE user_id IN (...). Что-то я сомневаюсь, что четырехэтажные запросы с подзапросами будут быстро работать, да еще и в MySQL.

Во-первых, почему есть unused память — возможно, что все файлы, к которым обращаются приложения, весят в сумме меньше, чем у вас свободной памяти, вот что-то остается невостребованным.

Почему дисковый кеш освобождается в пользу unused — может, у вас там ramfs/tmpfs и на ней удаляется файл, вот память и освобождается? Честно говоря, трудно еще какую-то версию предполжить. Может, вы отмонтировали блочное устройство и дисковый кеш, связанный с ним, освободился?

Если вы думаете, что есть руткит, наверно, стоит переустановить систему с нуля, чтобы не рисковать. Доказать отсутсвие руткита подобным наблюдением за системой нельзя.

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

А маркировка пакетвов — ненадежно, как вы можете гарантировать, что пользователь сам не промаркирует свой пакет? Да и возможно ли это вообще?

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

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

Начните с «Побег из психбольницы» Купера. Это самая простая и понятная книга. И, главное, она настроит ваше мышление в нужном направлении. После нее вы начнете смотреть на интерфейсы программ и устройств другим взглядом. Потом можете почитать Раскина (книга такая со штурвалом на обложке). Еще есть книга Купера «Об интерфейсе», но она толстая и немного скучноватая (так как очень подробная). А что дальше, я не знаю.

Начнем с того, что вам это вряд ли нужно для практических целей. В сутках 86400 секунд. Средний нормально написанный сайт (не друпал, не phpBB и прочий кривокод. Не Zend и не симфони) на PHP с использованием MySQL на среднем сферическом VPS в вакууме (с объемом памяти в 256 Мб) выдерживает 40-50 rps. Иногда даже он упирается не в процессор, а в ширину канала.

40-50 rps * 86 400 = примерно 1-2 млн хитов в сутки (так как нагрузка неравномерна по времени суток). Это примерно 100-200 тыс. среднеактивных посетителей (или 20-50 тыс., если речь не о блоге а о соцсети). Вряд ли у вас столько будет.

От идеи генерировать статический HTML давайте откажемся сразу: любой функционал чуть сложнее набора неизменных страниц так не сгенерируешь. Сложность кода и число зависимостей кешей будет расти в геометрических прогрессиях. Идея вставлять динамические фрагменты страниц через SSI/AJAX бесперспективна — они все равно будут вызывать запуск PHP, возможно даже увеличивая нагрузку. Лучше написать масштабируемое приложение с хорошим кешированием данных.

Хорошей идеей мог бы быть отказ от PHP в пользу Java/C++/.NET/D. Но это усложнит разработку: на этих языках все сложнее и дольше пишется.

Даже если на ваш блог ринутся все читатели Хабра, tema и еще нескольких блогов. Имея грубо написанный самопис на кривоPHP, у нас есть возможность масштабироваться раз в 10 с ростом нагрузки: ставим более мощное железо, расширяем память с 256 Мб до 64 Гб, ставим нормальный 8-ядерный процессор, нормальные диски. Тюним объем кешей MySQL, добавляем APC, начинаем понемного кешировать страницы в мемкеш. Далее, если нагрузка все равно растет, разносим код на несколько фронтендов, и, возможно, делаем мастер-слейв на MySQL. Можно скомпилировать PHP через hiphop.

Многим проектам этого хватает.

Но это тупой подход. Сделать репликацию, поставить балансировщик и нарастить память — ума много не надо. Даже обезьяна с этим справится. Гораздо лучше (и интереснее) изначально делать приложение с учетом возможности масштабироваться (что уж там стесняться) неограниченно. И куда как приятнее осознавать, что твое приложение может расти не хуже вконтакта с его отличниками и победителями математических олимпиад.

Представим, что у нас растет нагрузка и нам надо увеличиться до 1000 нод. Что касается фронтендов (в вашем случае на PHP), если не хватает мощности одного сервера, их (серверов) мы легко можем поставить хоть 1000, хоть 10000 (единственное, надо отказаться от сохранения сессий в локальных файлах, иначе никто не сможет залогиниться. Возможно, стоит перейти на REST и вообще отказаться от сессий). Перед ними ставим N балансировщиков на nginx, настраеваем round-robin в DNS (чтобы запросы валились на них поочередно).

Как работает round-robin в DNS вы можете увидеть, набрав nslookup vk.com несколько раз.

Мемкеш также (вы должны использовать мемкеш в приложении) легко масштабируется на N серверов. Лишь бы памяти было много и минимум гигабитная локальная сеть.

Раздача статики (картинки, CSS, скрипты) тоже банальна — ставим nginx на N серверов и забываем об этой проблеме. Единственная сложность — это раздача видео. Погуглите, на Хабре есть статьи про организацию CDN для видео и сопутствующие проблемы.

А вот с БД мы получаем затык. Даже если мы настроим мастер-слейв с несколькими слейвами, объем данных на запись на мастер от 1000 PHP-ных фронтендов положит любой сервер. Несмотря на то, что MySQL в сферической конигрурации на среднем сервере в вакууме легко делает 1-5 тысяч выборок по PKEY в секунду, на запись она работает гораздо хуже. Потому, раз уж мы делаем хайлоад сервис, то база тоже должна масштабироваться. Во-первых, можно разнести разные таблицы на разные сервера. Это мало. во-вторых, можно порезать таблицы на куски и разнести на разные сервера. Это то, что надо. То есть, допустим, в соцсети юзеры с ид 1-10000 хранятся на первом сервере в таблице users_1, юзеры 10000-20000 на втором сервере в таблице user_2, и так далее. Распределение записей и таблиц по серверам должно быть не намертво вбитое, а конфигурируемое, чтобы можно было переносить пачки записей с одного сервера на другой, уравновешивая нагрузку. Для этого придется написать небольшое приложение, показывающее распределение нагрузки и позволяющее переконфигурировать шарды.

Из такой схемы построения БД вытекают очевидные правила: запросы к БД не должны использовать JOIN (так как это невозможно при разнесенных таблицах, и дждойны плохо работают), должны использовать выборку только по индексам, лучше всего по PKEY (так как без индексов слишком медленно) и должны быть как можно проще. Они должны иметь небольшой LIMIT. Также, стоит пользоваться денормализацией данных: например, чтобы получить список фотографий пользователя, мы берем сериализованный список id этих фото, затем выбираем фото по id, а НЕ используем выборку по полю user_id в таблице photos (так как такая выборка не шардится и не масштабируется).

В общем, запросы должны быть тупыми как пробка и сводиться к SELECT… WHERE id IN (1, 2, 3). Кстати, как дополнительный плюс, такие запросы легко кешировать и очищать такой кеш.

Для сервисов типа поиска пользователей (как вконтакте) при такой схеме придется писать отдельные приложения на C++, которые будут индексировать БД и хранить данные в памяти. Увы, PHP тут не справится.

Вы можете почитать про архитектуру высоконагруженных проектов тут: www.insight-it.ru/highload/

А да, все. что написано выше, лишь теоретические рассуждения. Подумайте 10 раз, прежде чем применять это на практике.

Это трудный путь.

Вот, что должен знать хороший разработчик интерфейсов под iOS:

— понимать основы юзабилити и построения интерфейсов (есть книги, например, Раскин и Алан Купер). Но они большие, потому советую прочесть для начала «Побег из психбольицы» Купера, она маленькая и простая.
— понимать принципы графического дизайна, в плане того, какие задачи он решает и какими способами.
— научиться пользоваться графическими программами (это самый простой пункт).
— иметь чувство вкуса и эстетики, цветового баланса, пропорции, проще говоря, уметь делать красиво. Большинство людей не умеет.
— про шрифты, чтобы понимать какие-то основы, можно прочесть книгу А. Корольковой «Живая типографика» и книгу «Дизайн для недизайнеров» или «Недизайнерская книга о дизайне», как-то так. Она маленькая и простая.
— есс-но, прочесть мельком Apple HIG
— смотреть другие приложения, чтобы делать не хуже. Смотреть всякие сайты типа dribble и behance.

Возможно, вам все же проще поручить эту задачу кому-то другому?

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