Marek pisze:
>> Pewnie była podobna do tej, która przyświecała twórcy koła - żeby się
>> nie narobić ;]
>
> No zaraz zaraz... tylko po co wymyślać koło gdy wokół mnóstwo fabryk
[...]

Koło jest wymyślone, ale można je zmodyfikować na n sposobów. I to
właśnie chodzi.

> kół? Ponadto aplikacje online są dużo mniej ergonomiczne w zastosowaniu
> niż desktopowe. Nie wspomnę o tym, że desktopowe potrafić pewnie zawsze

Ergonomia to jedno, a użyteczność to drugie.

> będą znacznie więcej. Patrz np. Adobe czy Corel. Optymalizacja grafiki
> jest tam tylko jednym z elementów funkcjonalnych. Nic nigdzie nie trzeba
> wysyłać a wielokrotnie powtarzany proces eksportu grafiki w czasie
> rozwoju projektu trwa sekundy. Nie wyobrażam sobie pracy polegającej na
> edytowaniu pliku na kompie i wielokrotnym przesyłaniu zmodyfikowanej
> wersji do sieci.

Tę samą operację można wykonać na n sposobów. Co, kto woli. Nie ma
jednej, słusznej metody.

--
Peter

do góry

> Tę samą operację można wykonać na n sposobów. Co, kto woli. Nie ma
> jednej, słusznej metody.

Zgadzam się z Tobą tylr tylko, że jako web-developer nie jestem w stanie
zrozumieć powodu, dla którego znacznie miałbym wydłużyć sobie czas
realizacji projektu. Co otrzymuję w zamian?

Jeśli robię jakiś projekt w programie graficznym dedykowanym robieniu
projektów web to ma on tą funkcję w sobie. Po co więc gdzieś wysyłać i to
wielokrotnie dziennie tą grafikę - i to każdy z jej kawałków? To przecież
kupa niepotrzebnej pracy. Mało tego - "tradycyjne" programy graficzne, nie
dedykowane web-developerom, też miewają już taką funkcję - Adobe Photoshop,
Corel Photopaint, Corel Draw i wiele innych.

do góry

Marek pisze:
>> Tę samą operację można wykonać na n sposobów. Co, kto woli. Nie ma
>> jednej, słusznej metody.
>
> Zgadzam się z Tobą tylr tylko, że jako web-developer nie jestem w stanie
> zrozumieć powodu, dla którego znacznie miałbym wydłużyć sobie czas
> realizacji projektu. Co otrzymuję w zamian?

Przecież w tym sposobie kompresji grafiki nie wydłużasz sobie czasu
pracy. Zainstaluj sobie dodatek do Firefoksa, który jednym kliknięciem z
aktualnego URL kompresuje grafikę i pakuje to do jednego pliku zip.

> Jeśli robię jakiś projekt w programie graficznym dedykowanym robieniu
> projektów web to ma on tą funkcję w sobie. Po co więc gdzieś wysyłać i
> to wielokrotnie dziennie tą grafikę - i to każdy z jej kawałków? To
> przecież kupa niepotrzebnej pracy. Mało tego - "tradycyjne" programy
> graficzne, nie dedykowane web-developerom, też miewają już taką funkcję
> - Adobe Photoshop, Corel Photopaint, Corel Draw i wiele innych.

Zwróć uwagę na to, że algorytmy kompresji bardzo mogą się od siebie
różnić. Kiedy wydaje nam się, że Adobe Photoshop czy inny "kombajn"
wycisnął wszystko z kompresji obrazka, to może się okazać, że jest jakiś
mikro program lub inne rozwiązanie, co pozwoli ten sam obrazek
skompresować jeszcze ze 20% albo lepiej.

Przykład: Adobe Fireworks zapisuje plik PNG niechlujnie duży, ale już
GIMP nieco lepiej, a już całkiem po kompresji przez PNGOutWin plik staje
się jeszcze mniejszy. To pokazuje, że nie ma jedynego, słusznego
programu do kompresji grafiki, a jedynie metodą testów można dojść które
z rozwiązań daje optymalne wyniki.

--
Peter

do góry

Marek pisze:
>> Pewnie była podobna do tej, która przyświecała twórcy koła - żeby się
>> nie narobić ;]
>
> No zaraz zaraz... tylko po co wymyślać koło gdy wokół mnóstwo fabryk
> kół?

A po co jest mnóstwo fabryk kół, nie wystarczyłaby jedna?

> Ponadto aplikacje online są dużo mniej ergonomiczne w zastosowaniu
> niż desktopowe.

Ale masz coś na poparcie tej prawdy objawionej? Poślij od razu do
Googla, bo oni biedaki robią GMaila czy GCalc, Microsoft zdaje się też
coś swojego przygotowuje (ma), a ICQGo już stare jak świat jest. Daj im
znać że to nieergonomiczne, żeby kasy nie wyrzucali w błoto!

> Nie wspomnę o tym, że desktopowe potrafić pewnie zawsze
> będą znacznie więcej.

To nie zawsze jest zaletą, a już na pewno nie w przypadku gdy szukasz
prostego narzędzia do szybkiego wykonania jakiegoś zadania.

> Patrz np. Adobe czy Corel. Optymalizacja grafiki
> jest tam tylko jednym z elementów funkcjonalnych.

Każdemu wg potrzeb, nikt Ci nie każe odinstalowywać Photoshopa i używać
Smushita :]
Dla mnie niedorzecznością jest wydawanie kilku tysięcy na Photoshopa czy
Corela tylko po to, żeby zoptymalizować pliki. Tym bardziej iż nie mam
żadnego dowodu, że potrafią one to zrobić lepiej niż smushit/PngOptimizer.

> Nic nigdzie nie trzeba
> wysyłać a wielokrotnie powtarzany proces eksportu grafiki w czasie
> rozwoju projektu trwa sekundy.

W czasie rozwoju to ja sobie nie zawracam głowy takimi pierdołami, bo
jaki jest sens optymalizować obrazek, który i tak za 15 min. będę zmieniał?
Jak już pisałem Konradowi, wkrótce mają być dostępne źródła, więc sobie
dodam do skryptu pakującego i wysyłającego projekt jedną linijkę i
wszystko się samo zrobi. Takie koła to ja rozumiem!
A już teraz udostępniają API, jak chcesz to sobie możesz zautomatyzować
cały proces.

> Nie wyobrażam sobie pracy polegającej na
> edytowaniu pliku na kompie i wielokrotnym przesyłaniu zmodyfikowanej
> wersji do sieci.

Ja też nie :)


--
message[autor="PablO"]::after {
content:"Pozdrawiam";
}

do góry

** Paweł Piskorz <n...@p...nie?> wrote:

>>> Masz na myśli intranety? Bo nie widzę sensu zakazywać "przekazywania"
>>> grafik publicznie dostępnej witryny ;)

>> Jak tworzysz projekt to jest on publicznie dostępny?

> Prywatnie zajmuję się tylko cięciem i projekt udostępniam tak, żeby klient
> mógł sobie na żywo obejrzeć - więc tak, jest dostępny publicznie

No zaraz, ale klient może sobie obejrzeć to wcale nie == musi być dostępny
publicznie.

Jak rozumiem nie miewasz poważnych klientów czyli np. takich, którzy wraz z
uruchomieniem nowej linii produktów projektują nową stronę i bardzo by nie
chcieli aby konkurencja dowiedziała się jaka to linia produktów (może wydaje Ci
się to nierealne ale ja różne rzeczy już w życiu widziałem włącznie z
przekupywaniem agencji wykonującej projekt po to właśnie aby uzyskać takie
informacje).

Albo takich z którymi *standardowa* (szablonowo wymagana przez dowolną politykę
bezpieczeństwa zgodną z normami) umowa zobowiązuje Cię do zachowania poufności
(a udostępnienie projektu publicznie czy podmiotowi trzeciemu jest złamaniem
tej umowy - a, biznes jest biznes i można o to kruszyć kopie chociażby po to
abyś dał zniżkę przez ten incydent).

Albo takich z którymi również (aczkolwiek mniej już standardowa) umowa
zobowiązuje Cię do niepublikowania nieprzetestowanej wersji gdyż brak testów
jedzie po jakości, a jakość jedzie po wizerunku (Twojego klienta i również
Twoim).

Sorry może to moje zboczenie ale pracuję w organizacji w której takie rzeczy
zostaną N razy skontrolowane i potem ktoś się o coś takiego może mnie czepić.
Więc taki serwis odpada w przedbiegach (aczkolwiek wersja lokalna po analizie
co robi może być akceptowalna).

(...)

>>> <IfModule mod_deflate.c> # gziping css and js AddOutputFilterByType DEFLATE
>>> text/css application/x-javascript </IfModule>

>> To jest jak wywołać dany filtr, ale nie jaki to jest filtr.

> Pytałeś czego używam - ja używam tej dyrektywy Apache ;) A co za tym stoi to
> już nie pamiętam, wziąłem to z książki twórców YSlow. Zdaje się że Apache ma
> sobie wynegocjować z przeglądarką obsługiwaną kompresję,

Ale Ty mówisz o kompresji gzip na poziomie transmisji HTTP. Mi chodzi o
kompresję np. CSS, JS przez automagiczne usuwanie białych znaków, formatowania
czy np. minimalizowanie nazw zmiennych (z czytelnych na takie, które
zadziałają, ale nie połapiesz się w tym).

O to mi chodziło.

(...)

>> Ale np. content użytkownika też?

> To już nie moja brocha, ale z ciekawości sprawdzę ile można na obrazkach
> użytkownika oszczędzić. Jeżeli będzie warto, to się tym zainteresuje kogo
> trzeba :)

Tzn. oszczędza się tam gdzie warto np. wspomniałem o wersjach mobilnych - ten
sam content trzeba jakoś transformować. Używałeś kiedyś np. youtube przez
komórkę? To jest ten sam kontent *raz* wgrany przez użytkownika tylko
transformowany w zależności od medium.

--
+ ' .-. .
, * ) )
http://kosmosik.net/ . . '-' . kK

do góry

Konrad Kosmowski pisze:
> ** Paweł Piskorz <n...@p...nie?> wrote:
>
>> Prywatnie zajmuję się tylko cięciem i projekt udostępniam tak, żeby klient
>> mógł sobie na żywo obejrzeć - więc tak, jest dostępny publicznie
>
> No zaraz, ale klient może sobie obejrzeć to wcale nie == musi być dostępny
> publicznie.
>
> Jak rozumiem nie miewasz poważnych klientów czyli np. takich, którzy
[8<]

Nie mam takich klientów (no dobra, jeden był ;))

> Ale Ty mówisz o kompresji gzip na poziomie transmisji HTTP. Mi chodzi o
> kompresję np. CSS, JS przez automagiczne usuwanie białych znaków, formatowania
> czy np. minimalizowanie nazw zmiennych (z czytelnych na takie, które
> zadziałają, ale nie połapiesz się w tym).
>
> O to mi chodziło.

Nie korzystam z takich wynalazków. Jeżeli gzipuję pliki przy wysyłaniu,
to różnica pomiędzy wersją zminimalizowaną i skompresowaną, a tylko
skompresowaną nie jest warta zachodu. Lepiej mieć czytelnie sformatowane
pliki, tak żeby ich szukać nie trzeba było gdy zajdzie potrzeba zmian.

> Tzn. oszczędza się tam gdzie warto np. wspomniałem o wersjach mobilnych - ten
> sam content trzeba jakoś transformować. Używałeś kiedyś np. youtube przez
> komórkę? To jest ten sam kontent *raz* wgrany przez użytkownika tylko
> transformowany w zależności od medium.

Tja, używałem. RealPlayer ssie ;]


--
message[autor="PablO"]::after {
content:"Pozdrawiam";
}

do góry

** Paweł Piskorz <n...@p...nie?> wrote:

>> Ale Ty mówisz o kompresji gzip na poziomie transmisji HTTP. Mi chodzi o
>> kompresję np. CSS, JS przez automagiczne usuwanie białych znaków,
>> formatowania czy np. minimalizowanie nazw zmiennych (z czytelnych na takie,
>> które zadziałają, ale nie połapiesz się w tym).

>> O to mi chodziło.

> Nie korzystam z takich wynalazków. Jeżeli gzipuję pliki przy wysyłaniu, to
> różnica pomiędzy wersją zminimalizowaną i skompresowaną, a tylko
> skompresowaną nie jest warta zachodu.

A każda przeglądarka to łyka?

> Lepiej mieć czytelnie sformatowane pliki, tak żeby ich szukać nie trzeba było
> gdy zajdzie potrzeba zmian.

Ale przecież ja Ci nie każę mieć nieczytelnych - mówię o kompresowaniu ich w
locie.

Przykładowo masz tak, że:

- w /myscript.js masz wersję nieskompresowaną
- z HTML wywołujesz /cośtam/myscript.js i to wywołanie czegośtam kompresuje w
locie (oczywiście z buforem - robi to raz przy zmianie tylko)

I wilk syty i owca cała - masz i czytelną wersję i skompresowaną. BTW odnośnie
zmian to zmiany się wprowadza w środowisku rozwojowym, testuje w środowisku
testowym i publikuje na środowisko produkcyjne - takie kompresowanie w locie
pomaga w zarządzaniu całym tym procesem zmian. Ale chyba odnoszę wrażenie, że
nie zarządzasz zmianami...

>> Tzn. oszczędza się tam gdzie warto np. wspomniałem o wersjach mobilnych -
>> ten sam content trzeba jakoś transformować. Używałeś kiedyś np. youtube
>> przez komórkę? To jest ten sam kontent *raz* wgrany przez użytkownika tylko
>> transformowany w zależności od medium.

> Tja, używałem. RealPlayer ssie ;]

Co lepszego masz w komórce?

--
+ ' .-. .
, * ) )
http://kosmosik.net/ . . '-' . kK

do góry

Konrad Kosmowski pisze:
> ** Paweł Piskorz <n...@p...nie?> wrote:
>
>> Nie korzystam z takich wynalazków. Jeżeli gzipuję pliki przy wysyłaniu, to
>> różnica pomiędzy wersją zminimalizowaną i skompresowaną, a tylko
>> skompresowaną nie jest warta zachodu.
>
> A każda przeglądarka to łyka?

ZTCW nie.

>> Lepiej mieć czytelnie sformatowane pliki, tak żeby ich szukać nie trzeba było
>> gdy zajdzie potrzeba zmian.
>
> Ale przecież ja Ci nie każę mieć nieczytelnych - mówię o kompresowaniu ich w
> locie.

Ale mi chodziło o czytelne wszędzie, czyli również jak sobie odpalę tę
stronę w przeglądarce i zachce mi się na żywca edytować web developerem.
Poza tym uważam, że za mało to daje żeby się opłacało w to pakować. Tak
przynajmniej ludzie mogą sobie style/pliki js podglądnąć, skopiować,
może czegoś się nauczyć.

>> Tja, używałem. RealPlayer ssie ;]
>
> Co lepszego masz w komórce?

Nic, ale jednak miło by było gdyby potrafił korzystać (i domyślnie
korzystał) z tego samego połączenia wifi, którego używa odpalona obok
przeglądarka do otworzenia YouTube, a nie ssać bezczelnie po gprs bez
poinformowania mnie o tym.


--
message[autor="PablO"]::after {
content:"Pozdrawiam";
}

do góry

** Paweł Piskorz <n...@p...nie?> wrote:

>>> Nie korzystam z takich wynalazków. Jeżeli gzipuję pliki przy wysyłaniu, to
>>> różnica pomiędzy wersją zminimalizowaną i skompresowaną, a tylko
>>> skompresowaną nie jest warta zachodu.

>> A każda przeglądarka to łyka?

> ZTCW nie.

A jak skompresujesz JS czy CSS "moją" metodą to łyka?

>>> Lepiej mieć czytelnie sformatowane pliki, tak żeby ich szukać nie trzeba
>>> było gdy zajdzie potrzeba zmian.

>> Ale przecież ja Ci nie każę mieć nieczytelnych - mówię o kompresowaniu ich w
>> locie.

> Ale mi chodziło o czytelne wszędzie,

Albo kompresja albo czytelnie.

> czyli również jak sobie odpalę tę stronę w przeglądarce i zachce mi się na
> żywca edytować web developerem.

Czyli:

1. Nie zarządzasz zmianami (edytuje się to wersję rozwojową, dla której
kompresja jest wyłączona).
2. Przy dużym ruchu to Twój kaprys aby widzieć w przeglądarce może być
równoznaczny (totalnie z sufitu zapodaję) z 2% zwiększeniem ruchu - jeżeli
płacisz rocznie 3M złotych za łącza to te 2% warto wydać bo brak środowiska
testowego czy może lepiej je przeznaczyć na środowisko testowe?

> Poza tym uważam, że za mało to daje żeby się opłacało w to pakować.

Patrz wyżej punkt 2.

> Tak przynajmniej ludzie mogą sobie style/pliki js podglądnąć, skopiować, może
> czegoś się nauczyć.

Za to Ci płacą jak realizujesz projekt? Takie są wymagania? Aby się dało
"podglądnąć, skopiować, może czegoś się nauczyć"? Bardzo wydaje mi się, że
klient za to nie chce płacić - nie jest to jego potrzebą.

>>> Tja, używałem. RealPlayer ssie ;]

>> Co lepszego masz w komórce?

> Nic,

No więc o co Ci chodzi? Kup sobie nowszy telefon to będziesz miał może inny
kodek...

> ale jednak miło by było gdyby potrafił korzystać (i domyślnie korzystał) z
> tego samego połączenia wifi, którego używa odpalona obok przeglądarka do
> otworzenia YouTube,

W Nokii? Nie wiem mój korzysta z default.

> a nie ssać bezczelnie po gprs bez poinformowania mnie o tym.

A co za różnica, w sumie to grosze - jak mam wifi to wolę laptopa.

--
+ ' .-. .
, * ) )
http://kosmosik.net/ . . '-' . kK

do góry

On Thu, 02 Apr 2009 23:32:21 +0100, Paweł Piskorz <n...@p...nie?> wrote:

>> Ale Ty mówisz o kompresji gzip na poziomie transmisji HTTP. Mi chodzi o
>> kompresję np. CSS, JS przez automagiczne usuwanie białych znaków,
>> formatowania czy np. minimalizowanie nazw zmiennych (z czytelnych na takie, które
>> zadziałają, ale nie połapiesz się w tym).
>>
>> O to mi chodziło.
>
> Nie korzystam z takich wynalazków. Jeżeli gzipuję pliki przy wysyłaniu,
> to różnica pomiędzy wersją zminimalizowaną i skompresowaną, a tylko
> skompresowaną nie jest warta zachodu. Lepiej mieć czytelnie sformatowane
> pliki, tak żeby ich szukać nie trzeba było gdy zajdzie potrzeba zmian.

Ja się polubiłem z Makefile'ami i nie muszę przejmować się, um... "minifikowaniem"
plików. Deweloperska kopia strony ma nieskompresowane, a test i live mają
skompresowane.

To też bardzo pomaga gzipowi. Po kompresji plik jest 20-30% mniejszy niż z kompresją
bez minifikowania (jest bardziej regularny).


Poza tym ja lubię mieć skrypty podzielone na małe, logiczne pliki, ale nie będę
ruinował prędkości ładowania strony z tego powodu, więc i tak muszę je łączyć w jeden
duży plik. Dorzucenie minifikacji do skryptu to wtedy tylko jedna ekstra linijka.

--
http://pornel.net
this.author = new Geek("porneL");

do góry