Categories
Category: сметачи
Categories
За бързите уеб страници
В кратката ми „кариера“ съм имал възможността да се занимавам с доста натоварени уеб страници. Прекарал съм с колегите доста безсънни нощи, оптимизирайки заявки и код, пиейки бира и настройвайки сървърни конфигурации. И всичко това за да спестим още няколко милисекунди с поредната хитрост, да ощастливим потребителите като им предоставим съдържанието малко по-бързо.
Залисани в оптимизации, хиляди програмисти и администратори по света са се загубили в 80-те процента на Парето, смятайки че ако сървъра плюе страницата 2 пъти по-бързо, на потребителя ще му се струва, че се зарежда два пъти по-бързо. А всъщност изобщо не е важно колко по-бързо идва страницата. Важно е как му се струва на потребителя. Колкото и да е иронично времето за зареждане на HTML кода е рядко повече от 20% от времето на изпълнението на цялата заявка. Другите 80 отиват в заявки и обработка на скриптове, стилове и картинки.
Аз съм backend програмист и не се очаква да ви кажа как да оптимизирате лошите 80%. На мен ми дайте да направя 20-те 19.978 :-) Steve Sounders, обаче се занимава точно с това. Първо попаднах на една негова презентация, след това пробвах разширението му YSlow, а накрая се сдобих и прочетох книгата му. Определено си заслужават.
Методологията за създаване на по-бързи уеб страници е представена като 14 ясни и конкретни правила, които трябва да се спазват. Също така са изследвани десетте най-посещавани американски сайта на базата на тези правила. И в книгата и в презентацията има много реални примери, които да ви помогнат в осъществяването на правилата на практика. Още примери има и на сайта на автора, където може наистина да усетите разликата между страници, които спазват някое правило и такива, които не го спазват. Всичката информация е организирана доста добре и няма да ви е трудно да се справите с процеса по „преход“ към по-бърз сайт.
Две много важно уточнения преди да захвърлите сървърната оптимизация. Дори зареждането на кода на страницата да отнема само 20%, то без него няма да се зареди нищо. Другата причина да не зарязвате backend забързването е, че колкото по-бързо сървъра си върши работата, толкова повече заявки ще може да обработи за единица време, което значи по-малко сървъри и разбира се – по-малко пари.
Откритията на Sauders и екипа му из Yahoo! не решават проблема с оптимизацията на уеб сайтове. Те просто добавят още един – този за front-end оптимизацията.
Categories
Демончетата се върнаха
Предварителната информация за FreeBSD 7.0 изглежда доста вълнуващо.
Тръгнах да пиша коментар към публикацията на Мишел за неговите езиково-преводни неволи, но се разпрострях твърде надълго и предпочетох да си го напиша тук.
Основният проблем, който стои пред нас е да локализираме приложение, което се ползва от милиони хора по целия свят. Без магическа пръчка.
Първа стъпка: превод
Да се плаща на преводачи на 50+ езика, за хиляди (десетки хиляди в случая на Google) низове, които се променят всеки част просто не е scalable. Нито откъм пари, нито откъм управление на подобни човешки ресурси.
Единият вариант е да се плати за превод на приложението на няколко избрани езика – първите по трафик/брой потребители.Така, например, са направили flickr. Заради професионалните преводачи качеството е високо, всички низове са преведени, но пък никога няма да се появи flickr на български и flickr никога няма да завладее нашия пазар (което с оглед на нашенските сайтове за споделяне на снимки е жалко). От друга страна те не усещат това финансово, тъй като са покрили 99% от потребителите, които им носят реални приходи.
Схемата на Google е доста по-сложна. За някои избрани приложения (Gmail) и избрани езици (немски, френски) използват професионални преводачи, но някои части дори и от тези приложения могат да бъдат редактирани от простосмъртни. Отгоре пофледнато е малко манджа с грозде, но е факт, че са постигнали задоволително качество без да си усложняват живота безкрайно много. Вярно – има дразнещи преводи, но приложенията са напълно използваеми в общия случай. В частния случай, се чудя дали някой наистина може да си иска Великобританията.
Един трети вариант е да сте били далновидни и да сте си базирали приложението на проект с отворен код. В WordPress.com повече от една трета от низовете идват от wordpress.org, който пък е преведен на петдесетина езика. Ето как в доста от случаите сме с една-трета рамо напред :-) Останалите низове, също се превеждат от доброволци. За радост все още успяваме да реагираме бързо на грешки и ако някой подаде сигнал, обикновено до ден (зависи дали се сетя да погледна) се поправят. Моите наблюдения показват, че езиците, които имат най-много трафик са най-пълно и най-качествено преведени (за последното съдя от броя доклади за грешки), което разбира се е напълно логично. Като цяло доброволните преводи да удачен вариант при условие че се окуражават потребителите да докладват за грешки и някой на практика обръща внимание на тези доклади.
След като сте си превели приложението трябва някак да окуражите потребителите да ползват собствения си език. Особено тези, които не разбират английски. Това обаче ще остане за втората част – бяла магия.
Categories
По-добри уеб приложения
След безценното си разширение за Firefox Better GMail (препоръчвам силно) добрите хора от Lifehacker са пуснали още едно: Better Flickr.
Поуката: предимството да правите хубави уеб приложения е, че потребителите им ще намерят начин да ги направят още по-добри.