22 апреля, 2011 | Нет комментариев
Дочитал «Чистый код».
1. Я не пишу на яве. В книге примеры для Явы.
2. Книга о том как писать код оптимально.
Очень хорошо раскрыта мысль как называть переменные в коде, как выбирать имена функциям, что именно в коде стоит комментировать и даются исчерпывающие ответы почему стоит делать именно так.
О объектах — они должны быть небольшими.
Ну пожалуй и всё.
Вывод: Книгу прочитать нужно. Она о мелочах. В ней нет информации о том как спроектировать сложную систему, в ней информация о том как писать код. Красивый и понятный.
20 апреля, 2011 | Нет комментариев
1. ЕСН+НДФЛ+НДС=34+13+18=65%
2. 100 рублей с 2000 человек/месяц — приличные деньги.
11 апреля, 2011 | Нет комментариев
При частой миграции виртуалки Windows XP с AMD на Intel и с однопроцессорной настройки на многопроцессорную виндовоз умирает с ошибкой на processr.sys.
Это лечится внесением правок в реестре при загрузке через безопасный режим.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Processor
Or
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Intelppm
Установить значение для ключа ‘Start’ в ‘4’.
4 апреля, 2011 | Нет комментариев
1 апреля, 2011 | Нет комментариев
С празднегом.
я ведь тоже где-то на 5% математег по состоянию души =)
31 марта, 2011 | Нет комментариев
Несколько шедевров, как веб дизайнеры креативят. Это или согласовано с заказчиками или отжег. Если есть час времени, можно заценить:
25 марта, 2011 | Нет комментариев
В продолжение решения задачи: Реляционка или не реляционка
Пройдя первый этап: MySQL vs MongoDB. Сравнение скорости insert Создания пользователей.
Пройдя второй этап:MySQL vs MongoDB. Более сложный insert (для mongodb) Создания друзей.
Пройдя третий этап: MySQL vs MongoDB. Более сложный insert (для mongodb) часть 2. Создания фотографий у каждого пользователя
Теперь пометим у каждого френда (100 френдов у каждого из 1000 пользователей) по 50 фотографий из 100 просмотренными. Получается 1000*100*50=5000000 (пять миллионов записей):
Для MySQL это вставка в таблицу who_view_photo записи с id_photo и id_user просмотревшем его.
Для MongoDB это изменение существующих объектов в коллекции пользователей. Причём мы меняем 3-й уровень объекта в глубину:
Посмотрим насколько шустро отработает наш MongoDB. Ему уже приходится в каждом объекте содержать информацию о 100 друзьях и 100 фотографиях (1000 записей).
По оси Х-время, по оси Y-количество случаев с данным временем. На примере вставки первых 50000 элементов (просмотров фотографий):
Вывод: Объекты MongoDB разжирнев, обрабатываются дольше, чем банальная вставка значения в таблицу MySQL. Но даже содержа 1000 значений в объекте, выполняя фактически операцию update к объекту (меняя его содержимое) мы получаем все-лишь двукратное замедление, что радует.
25 марта, 2011 | Нет комментариев
В продолжение решения задачи: Реляционка или не реляционка
Пройдя первый этап: MySQL vs MongoDB. Сравнение скорости insert Создания пользователей.
Пройдя второй этап:MySQL vs MongoDB. Более сложный insert (для mongodb) Создания друзей.
Создадим фотографии пользователей. Каждому пользователю по 100 фотографий.
Для MySQL это обычное создание записи в таблице:
Для NoSQL это добавление в коллекцию пользователей из MySQL vs MongoDB. Более сложный insert (для mongodb) ещё одного поля photos, являющегося множеством элементов.
И сравниваем производительность выполнения вставки 100 фотографий каждому из 1000 пользователей (100000 элементов).
По оси Х-время в секундах, по оси Y-количество случаев с данным временем выполнения(основной кусок увеличен):
Вывод: нужно понимать, что для MySQL — создание фотографии лишь вставка новой записи в таблицу фотографий, а для MongoDB — изменение существующего объекта, в котором уже содержится 100 друзей, созданных в предыдущем этапе, и ещё добавляется 100 элементов фотографий. Но при всём этом MongoDB половину операций (~50000) отработало за 0.0001 секунды, а MySQL редко ранее 0.0005 секунды. И MongoDB пришлось проделать гораздо большую работу (обновить существующие объекты).
IAD 