Известно, что следуя идеям старой школы, а именно, добавляя ссылки на JS и CSS в страницы, может обернуться большим временем загрузки страницы. Браузер отображает страницу по мере скачивания, но останавливается, если натыкается на тег script со ссылкой, до того момента, пока скрипт не будет загружен и выполнен. Сайты стали использовать всё большее количество скриптов, начальное отображение страницы занимает всё больше времени, к примеру, на этой странице, которую вы читаете, 13 скриптов, 7 из которых находятся в head’е. Ко всему прочему, некоторые браузеры по-прежнему придерживаются ограничений на одновременное количество загрузок с одного хоста.
Сразу предлагаю принять, что все JS файлы минимизированы, и передаются в сжатом виде.
Существует несколько решений, как то:
— поместить стили и скрипты прямо в страницу;
— установка аттрибутов async/defer тегу script;
— склеить все скрипты в один файл;
— помесить ссылки на скрипты в конец body;
— разместить все файлы на CDN/на разных хостах;
— свой вариант…
Эти решения работают, каждое лучше или хуже в зависимости от того, как построен сам сайт, но обладают рядом недостатков, которые я опишу ниже.
Существует интересная техника, которая решает проблему паузы перед начальным отображением страницы, а заодно добавляет некоторые удобства. Рискну предположить, что техника эта многим знакома, но тем не менее здесь я о ней упоминаний не видел.
Началось всё, конечно, с того, что я взялся за один проект, и в какой-то момент мне показалось, что простенькая страница достаточно долго загружается, и посмотрел на график загрузки, и на результаты YSlow. Огонь на секунду потух в моих глазах, но зная, что может быть лучше, я полез искать,
Архив Январь 7, Суббота, 2012
Как обладатель смартфона со стеклом Gorilla Glass, могу сказать, что это — действительно отличная технология защиты. У меня было достаточно много сотовых телефонов и коммуникаторов, однако в большинстве моделей самым слабым местом был дисплей. Нет, не в том смысле, что он бился и трескался, просто даже чехол не мог быть гарантией того, что в один прекрасный момент на поверхности дисплея не образуется царапинка. А эти царапинки здорово достают.
Предисловие
Я уже долгое время ничего не исследую, так сказать ушел на покой. Но тут мне на глаза попалась очередная поделка немало известного в определенных кругах PE_Kill'a. Т.к. мне довелось решать его предыдущую поделку в рамках CRACKL@B Contest 2010, которая в свою очередь была довольно интересна, я решил взглянуть на его новое «детище».
Что вас ждет под катом: подделка CRC32, брут ключа для RC4, факторизация для RSA, а также использование коллизии для MD4 и генерация двух разных сообщений с одинаковыми хешеми. Всё это и многое другое под катом.
Примечание. Этот пост в блоге Дэмиена Каца, создателя CouchDB, вызвал широкий резонанс. В конце данного топика опубликован ответ одного из многочисленных оппонентов Каца, мнение которого кардинально противоположно автору.
Каково будущее CouchDB? Это Couchbase.
Удивлены? Спросите, как же Apache CouchDB? Что ж, это отличный проект. Я основал его, написал первые версии почти полностью самостоятельно, потратил огромное количество нервов, пота и крови на него. Я очень им горжусь и тем влиянием, которое у него было. А сейчас я и команда Couchbase готовы двигаться дальше. Конечно, CouchDB — отличная система, но мы делаем его наследника: Couchbase Server. Продукт и проект с похожими возможностями и задачами, но более быстрый, более масштабируемый, более подходящий и для пользователей, и для разработчиков. И, определённо, не часть Apache.
Примечание переводчика: робот офигенно умный! Обязательно посмотрите видео под катом!
Первое небольшое введение смотрите тут — http://www.youtube.com/watch?v=OJiMUzJHYFk
Я начал с игрушки «Интерактивный ВаллИ». Текущая цена на toys’r'us составляет $34.99.
Я увлекаюсь роботами и у меня есть большой опыт в программировании и дизайне, чтобы дать роботам эмоции и жизнь. Первый совет, который я могу дать вам, — вы должны быть уверены. Второй совет — будьте креативным. Используйте их вместе, а всё остальное ваш ум сделает за вас 
В магазинах есть много доступных запчастей. Моя мастерская не представляет из себя ничего особенного. Я стараюсь закупать те детали, которые подешевле. Иногда я разбираю другие игрушки, потому что сервоприводы, к сожалению, самые дорогие из всех запчастей
Для крепежа я использую кабельные стяжки, а также маленькие винтики, болтики и гаечки. Все они доступны в дешёвых наборах для сборки в местном магазине.
Чтобы изменять корпуса, я использую инструменты Dremel, а иногда и свой паяльник, чтобы расплавить пластмассу. При шлифовке, пожалуйста, имейте пылесос поблизости. Внимание: При плавке, держите открытым окно с вентилятором!
Как не крути, а в новогодние праздники, риск порчи файлов значительно возрастает. Не миновала сия беда и меня. Как не трудно догадаться, я перепутал диск при форматировании и… да-да, все что было нажито неправедным путем непосильным трудом, в один момент было уничтожено.
Помянув сборник софта и архив отсканированных справочников, я задумался над вопросом бекапов. И… Пришел к выводу, что того что мне в самом деле требуется, нет. Точнее конечно же есть, но либо стоит дорого, либо работает не так, как мне бы того хотелось.
Не так давно я задавал вопрос в Groovy mail-list — есть ли какой-то устойчивый список вещей, которые надо избегать при написании высокогопроизводительного на Groovy. Среди прочих советов, один из главных разработчиков Groovy, Jochen «blackdrag» Theodorou указал, что в общем случае, зачастую использование конкретного типа при объявлении переменной (например, MyType var =… вместо def var = …) может ухудшить производительсть из-за накладных расходов на проверку типов и, если нужно, их приведение.
По утвеждениям разработчиков Groovy, многие из проблем в этом области наблюдались в версиях вплоть до 1.7 и были затем исправлены во время большой работы по общей оптимизации рантайма, проделанной в версии 1.9. Ниже, однако, небольшой эксперимент, который показывают эти накладные расходы даже на Groovy 1.8.3.
Перед этим экспериментом будет полезно просмотреть следующую статью — groovy.codehaus.org/From+source+code+to+bytecode, где рассказывается про то, как по шагам исходный код на Groovy преобразуется в байткод JVM, а так же почитать какую-нибудь вводную статью в собственно байткод, например эту — www.ibm.com/developerworks/ibm/library/it-haggar_bytecode/.
Недавно взглянул на сорцы Farseer Physics Engine. Стало интересно как в этом движке реализован динамический объект. Как и ожидал, не встретил там привычных мне дифференциальных уравнений и их дискретных реализаций в виде разностных уравнений или дискретных моделей пространства состояний. Главная отмазка заявляемая причина отказа от «честной» механики во многих игровых физических движках — излишняя сложность работы с дифференциальными уравнениями и слишком большая вычислительная нагрузка.
Команда разработчиков Nokia Research Center выкатила по-настоящему удивительное демо картографического сервиса на WebGL. Кроме красоты самой 3D-модели, вызывает восхищение минимальное потребление CPU при рендеринге, плавный скроллинг и больше всего — возможность произвольно менять угол зрения и вращать модель.
Возможно, в будущем этот проект придёт на смену нынешнему сервису Nokia Maps. Жаль, что основного разработчика движка данного сервиса — компанию C3 Technologies — недавно поглотила Apple, так что на продление соглашения с Nokia можно не рассчитывать.