🚀 go-pugleaf

On 16 Oct 2005 01:52:14 -0700, pawelg24@poczta.onet.pl wrote:

>witam
>czy ktos wie w jakis sposob mozna pod c++ odczytad dany sektor dysku??

Obiektowo?...

A.L.

Dnia Sun, 16 Oct 2005 09:22:50 -0500, A.L. skrobie:
> On 16 Oct 2005 01:52:14 -0700, pawelg24@poczta.onet.pl wrote:

> >witam
> >czy ktos wie w jakis sposob mozna pod c++ odczytad dany sektor dysku??

> Obiektowo?...

No przecież sektor też jestem obiektem... kurde, po co ja to powiedziałem.
Nieważne. :)

Panie Andrzeju, coś panu ta stabilizacja najwyraźniej nie służy. Żadnych
zgryźliwych komentarzy, złośliwych uwag itd...

A chętnie np. bym się dowiedział, jak się panu widzą np. metody Agile.
Interesuje mnie to o tyle, że jeszcze jakiś czas temu obsobaczałeś pan tu
Extreme Programming.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java does not have pointers!"

On Sun, 16 Oct 2005 20:15:46 +0000 (UTC), Sektor van Skijlen
<ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

 
>Panie Andrzeju, coś panu ta stabilizacja najwyraźniej nie służy. Żadnych
>zgryźliwych komentarzy, złośliwych uwag itd...
>
>A chętnie np. bym się dowiedział, jak się panu widzą np. metody Agile.
>Interesuje mnie to o tyle, że jeszcze jakiś czas temu obsobaczałeś pan tu
>Extreme Programming.

Extreme Programming dalo ciala wiec przemianowano je na Agile :)

Przeciez TO:

http://agilemanifesto.org/principles.html

wyglada jak Manifest Komunistyczny. I mniej wiecej tak samo ma sie
do rzeczywistosci.

A.L.

On Sun, 16 Oct 2005 16:15:03 -0500, A.L. <alewando@kapturek62.com>
wrote:

>On Sun, 16 Oct 2005 20:15:46 +0000 (UTC), Sektor van Skijlen
><ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:
>
> 
>>Panie Andrzeju, coś panu ta stabilizacja najwyraźniej nie służy. Żadnych
>>zgryźliwych komentarzy, złośliwych uwag itd...
>>
>>A chętnie np. bym się dowiedział, jak się panu widzą np. metody Agile.
>>Interesuje mnie to o tyle, że jeszcze jakiś czas temu obsobaczałeś pan tu
>>Extreme Programming.
>
>Extreme Programming dalo ciala wiec przemianowano je na Agile :)
>
>Przeciez TO:
>
>http://agilemanifesto.org/principles.html
>
>wyglada jak Manifest Komunistyczny. I mniej wiecej tak samo ma sie
>do rzeczywistosci.
>
>A.L.

P.S. Dominujaca w przemysle metodologia to "debile development" i
niewiele sie tu da zmienic. Natomiast do autorow zarownio XP jak i
Agile mam instunktowna a silna niechec, zwlaszcza dotyaczca ich
motywacji jak i ekspiriencji. Jak w starym dowcipie o komunizmie,
powinni to najpierw przebadac na myszach. Osobiscie.

A.L.

Dnia Sun, 16 Oct 2005 16:15:03 -0500, A.L. skrobie:
> On Sun, 16 Oct 2005 20:15:46 +0000 (UTC), Sektor van Skijlen
> <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

>  
> >Panie Andrzeju, coś panu ta stabilizacja najwyraźniej nie służy. Żadnych
> >zgryźliwych komentarzy, złośliwych uwag itd...
> >
> >A chętnie np. bym się dowiedział, jak się panu widzą np. metody Agile.
> >Interesuje mnie to o tyle, że jeszcze jakiś czas temu obsobaczałeś pan tu
> >Extreme Programming.

> Extreme Programming dalo ciala wiec przemianowano je na Agile :)

> Przeciez TO:

> http://agilemanifesto.org/principles.html

> wyglada jak Manifest Komunistyczny. I mniej wiecej tak samo ma sie
> do rzeczywistosci.

No dobrze, ale w takim razie jedno zasadnicze pytanie: to co pan proponujesz w
zamian? Bo mozliwosci sa zgola dwie:

1. Robic soft "na chama". To juz wielu przerabialo (a i wielu uprawia nadal) i
raczej taki sposob nie nadaje sie dla firm, ktore chcialyby robic i na czas i
niezawodnie.

2. Stosowac "tradycyjny proces". Tak sie sklada, ze wlasnie tradycyjny proces
ma dokladnie ten sam problem, co komunizm: doskonala technologia, tylko nie
sprawdza sie w praktyce, bo ludzie nie chca sie do tego dostosowac. Np. nie
umieja zrobic designu tak, zeby nie poprawiac go po fakcie, a klient tez nie
moze zrozumiec, ze nie powininen zglaszac poprawek, jak juz projekt jest w
toku.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java does not have pointers!"

On Mon, 17 Oct 2005 13:15:04 +0000 (UTC), Sektor van Skijlen
<ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:
 
>
>2. Stosowac "tradycyjny proces". Tak sie sklada, ze wlasnie tradycyjny proces
>ma dokladnie ten sam problem, co komunizm: doskonala technologia, tylko nie
>sprawdza sie w praktyce, bo ludzie nie chca sie do tego dostosowac. Np. nie
>umieja zrobic designu tak, zeby nie poprawiac go po fakcie, a klient tez nie
>moze zrozumiec, ze nie powininen zglaszac poprawek, jak juz projekt jest w
>toku.

Alez klientow zacheca sie zeby zrobili poprawki gdy projest jest w
toku, bo na tym firma zarabia pienidze. Nei wiem w jakiej dziedzinei
Pan parcuje i skad pochodza Panskie doswiadczenia, ale moja firma
nie robi systemow "od podstaw". Jest spora ilosc podstawaowych
modulow ktore oferuja dosyc podsatwowa ale bogata funkcjonalnosc.
Spzredawaniem zajmuje sie "sales department", a jak juz klient da
sie zlapac to wkraczaja faceci od "project analysis" i robia "gap
analysis" czyli okreslaja co ma byc dorobione. Potem wspolnie z
klientem ustalaja "acceptance protocol" czyli kryteria na mocy
ktorych klient uzna ze sprzedano mu to co zazadal. Potem to idzie do
"legal department" naszego i klienta, i panowie prawnicy
zatwierdzaja papiery. A na koniec naczalstwo podpisuje.

Wiec jak klient przyjdzie potem i powie ze che cos zmienic, to sie
szybko oblicza ile go to bedzie kosztowalo, a na pewno bedzie go
kosztowalo duzo i jak sie zgodzi to sie zmeinia papiery jak wyzej,
biorac pod uwage ze w poczatkowej umowie jest napisane ze wszelkie
zmiany beda robione wedlug innych stawek.

Wiec nei wiem skad te koncepcje o "wlaczeniu klienta do procesu
programowania". Noze w jakeijs firmie garazowej to dziala, moze jak
trzeba zrobic "bazke danych" dla Cioci Kloci czy pierdolnac
"stronke" dla Pana Jozia to mozna negocjowac "w trakcie". Ale to,
you know, raczej margines...

To wlasnie moje brzydkie podejrzenia co do autorow roznych
wstzrasajacycj metodologii. Mam niejakei podejzrenie ze wiedza oni
tyle o programowaniu komercjlnym co ja o japonskim teatrze Kabuki.

A.L.

Dnia Mon, 17 Oct 2005 08:28:45 -0500, A.L. skrobie:
> On Mon, 17 Oct 2005 13:15:04 +0000 (UTC), Sektor van Skijlen
> <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:
>  
> >
> >2. Stosowac "tradycyjny proces". Tak sie sklada, ze wlasnie tradycyjny proces
> >ma dokladnie ten sam problem, co komunizm: doskonala technologia, tylko nie
> >sprawdza sie w praktyce, bo ludzie nie chca sie do tego dostosowac. Np. nie
> >umieja zrobic designu tak, zeby nie poprawiac go po fakcie, a klient tez nie
> >moze zrozumiec, ze nie powininen zglaszac poprawek, jak juz projekt jest w
> >toku.

> Alez klientow zacheca sie zeby zrobili poprawki gdy projest jest w
> toku, bo na tym firma zarabia pienidze.

Ależ nie powiedziałem wcale, jaka jest praktyka, tylko jakie są wstępne
założenia "tradycyjnego" procesu. A założenia tradycyjnego procesu są takie,
że wedle wymagań robi się design, potem wedle designu kod.

Że nie ma to wiele wspólnego z praktyką, to ja o tym doskonale wiem, tylko nie
wiem, czy pan sobie zdaje z tego sprawę, że to właśnie świadczy o wadach
tradycyjnego procesu.

Gdyby rzeczywiście to wszystko robić na poważnie i faktycznie zgodnie z
tradycyjnym procesem, to koszt wprowadzenia poprawek w trakcie projektu jest
dość spory. Trzeba bowiem wprowadzić zmiany w wymaganiach, potem do tego
dostosować design, potem kod... a jak jesteśmy w trakcie fazy pisania kodu to
i tak jest dobrze. Bo jak klient zgłosi poprawkę w fazie SST, to jeszcze jest
cała seria innych rzeczy do poprawki.

Klienta oczywiście trzeba skroić za taki kaprys, żeby sobie nie myślał. Ale
firma jednocześnie najczęściej obchodzi proces i właśnie dzięki temu to, co
klient zapłaci nie idzie na pokrycie kosztów, tylko do kieszeni.

> Nei wiem w jakiej dziedzinei
> Pan parcuje i skad pochodza Panskie doswiadczenia, ale moja firma
> nie robi systemow "od podstaw". Jest spora ilosc podstawaowych
> modulow ktore oferuja dosyc podsatwowa ale bogata funkcjonalnosc.

No to bardzo podobnie, jak u mnie.

> Spzredawaniem zajmuje sie "sales department",...
[...]
>A na koniec naczalstwo podpisuje.

Nie no ta faza jest akurat "poza mną". Stanowi element, powiedziałbym,
wyższego rzędu. W przypadku niektórych produktów softwarowych zresztą tej fazy
nie ma w ogóle, więc przyjmijmy, że to w ogóle nie jest część tworzenia
oprogramowania.

> Wiec jak klient przyjdzie potem i powie ze che cos zmienic, to sie
> szybko oblicza ile go to bedzie kosztowalo, a na pewno bedzie go
> kosztowalo duzo i jak sie zgodzi to sie zmeinia papiery jak wyzej,
> biorac pod uwage ze w poczatkowej umowie jest napisane ze wszelkie
> zmiany beda robione wedlug innych stawek.

Nie, no oczywiście.

> Wiec nei wiem skad te koncepcje o "wlaczeniu klienta do procesu
> programowania".

Z praktyki, panie Andrzeju.

Stąd na przykład, że klient zwykle jeśli wie, czego chce, to jest wyjątkiem i
raczej na 100% nie wie wszystkiego, jeśli już nawet jest takim wyjątkiem.

Klient zwykle nie wie, czego chce. Dopiero na różne pomysły będzie wpadał
później.

Projektant też z reguły nie wie, jak napisać design, żeby można było się
trzymać tego designu już do końca.

Implementor zwykle wpada na najlepsze pomysły na usprawnienie wszystkiego, bo
dopiero gdy mamy coś działającego, wtedy wychodzi na wierzch, ile głupich
pomysłów miał projektant i jakie wspaniałe rozwiązania jakoś nie przyszły mu
do głowy.

Taka jest praktyka. Przeżyłem już kilka projektów i jeszcze mi się nie
zdarzyło, żeby było inaczej.

Oczywiście, gdybyśmy mieli idealnych projektantów, idealnych programistów,
idealnych klientów, to pewnie tradycyjny proces by się sprawdził, ale tacy
istnieją tylko w tzw. bajkach.

> Noze w jakeijs firmie garazowej to dziala, moze jak
> trzeba zrobic "bazke danych" dla Cioci Kloci czy pierdolnac
> "stronke" dla Pana Jozia to mozna negocjowac "w trakcie". Ale to,
> you know, raczej margines...

Z tego co się orientuję, to tak właśnie w praktyce wygląda tworzenie
oprogramowania w niektórych dużych firmach (np. Lucent, Ericsson, Motorola).
Może te firmy to margines, nie wiem.

> To wlasnie moje brzydkie podejrzenia co do autorow roznych
> wstzrasajacycj metodologii. Mam niejakei podejzrenie ze wiedza oni
> tyle o programowaniu komercjlnym co ja o japonskim teatrze Kabuki.

Ja poznałem tą metodologię trochę od innej strony - ze sprawozdania szefa
zespołu, który tą metodą prowadził projekt. Projekt zakończył się
spektakularnym sukcesem. Przy czym nie było ani kajania się przed klientem,
ani problemów z dotrzymaniem terminu, ani nadgodzin, ani dużego backlogu,
ani syfiastego kodu, co w tradycyjnym procesie jest "rule rather than
exception".

To w sumie tylko taki przykład. Innym przykładem jest dokonywanie poprawek w
designie i w wymaganiach, kiedy produkt jest już na etapie SST. Te poprawki
oczywiście robi się już na samym końcu, jak już kod dawno obracają testerzy.

Jeszcze innym przykładem jest skuteczne zniechęcanie do refactoringu i
wszelkich innych "drobnych zmian". Co bardzo skutecznie podwyższa koszty pracy
nad oprogramowaniem. A że soft najpierw się pisze tak, żeby działał, a potem
dopiero tak, żeby wyglądał, to tego się napatrzyłem wystarczająco dużo.

Osobiście, z drugiej strony, uczestniczyłem w projekcie prowadzonym
"tradycyjną" metodą. No i oczywiście proces procesem, a jak trzeba coś było
zrobić na skróty, to się robiło. Ten projekt też zakończył się spektakularnym
sukcesem, do działki robionej przez nas nie zgłoszono (o ile pamiętam) ani
jednego błedu. Ale ile nas to kosztowało nadgodzin i nerwów, to aż strach
wspominać. Bynajmniej tego sukcesu nie zawdzięczamu procesowi, tylko co
najwyżej sprawnej organizacji pracy i być może PODSTAWOWYM założeniom procesu.
Nie od rzeczy jest też wspomnieć, że po rozpoczęciu projektu staffing
wymieniono w 80%, czego przecież nie przewidywał ani projekt, ani estymaty, na
bazie których wynegocjowano termin oddania projektu. Z tego co policzyłem "na
odwrocie koperty", te tzw.  "aktywności procesowe", które nie dawały kodowi
praktycznie żadnych korzyści (np. wykryto błąd, który i tak by został wykryty
na UT) z nawiązką rekompensują spędzone wtedy nadgodziny.

Taki jest mój punkt widzenia. I dlatego uważam, że to właśnie tradycyjny
proces powstał w środowiskach naukowych, gdzie poważnego oprogramowania nikt
nigdy nie pisał.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java does not have pointers!"

A.L. <alewando@kapturek62.com> wrote:
> modulow ktore oferuja dosyc podsatwowa ale bogata funkcjonalnosc.
> Spzredawaniem zajmuje sie "sales department", a jak juz klient da
> sie zlapac to wkraczaja faceci od "project analysis" i robia "gap
> analysis" czyli okreslaja co ma byc dorobione. Potem wspolnie z
> klientem ustalaja "acceptance protocol" czyli kryteria na mocy
> ktorych klient uzna ze sprzedano mu to co zazadal. Potem to idzie do
> "legal department" naszego i klienta, i panowie prawnicy
> zatwierdzaja papiery. A na koniec naczalstwo podpisuje.

sensowna procedura, ale przeciez nie konczy sie ona projektem. A jak z 
tego przejsc do gotowego produktu, skoro projektu nie ma?

> Wiec nei wiem skad te koncepcje o "wlaczeniu klienta do procesu
> programowania".

moze po to, aby produkt (a nie tylko specyfikacja) optymalnie odpowiadal 
potrzebom klienta? Zauwaz ze z jednej specyfikacji moga wyjsc zupelnie 
rózne produkty, i z perspektywy klienta jeden bedzie dzialal lepiej, 
drugi gorzej (np. ze wzgledu na wygode uzytkowania). Mimo ze oba przejda 
równie dobrze "acceptance tests".


B.

On Thu, 20 Oct 2005 16:12:26 +0100, "Bronek Kozicki" <brok@rubikon.pl>
wrote:

>A.L. <alewando@kapturek62.com> wrote:
>> modulow ktore oferuja dosyc podsatwowa ale bogata funkcjonalnosc.
>> Spzredawaniem zajmuje sie "sales department", a jak juz klient da
>> sie zlapac to wkraczaja faceci od "project analysis" i robia "gap
>> analysis" czyli okreslaja co ma byc dorobione. Potem wspolnie z
>> klientem ustalaja "acceptance protocol" czyli kryteria na mocy
>> ktorych klient uzna ze sprzedano mu to co zazadal. Potem to idzie do
>> "legal department" naszego i klienta, i panowie prawnicy
>> zatwierdzaja papiery. A na koniec naczalstwo podpisuje.
>
>sensowna procedura, ale przeciez nie konczy sie ona projektem. A jak z 
>tego przejsc do gotowego produktu, skoro projektu nie ma?
>

Nie robi sie projektu metoda "kota w worku". To "nowoczeste
metodologie" sugeruja aby zaczynac kodowanie zanim sie zacznie myslec.

>> Wiec nei wiem skad te koncepcje o "wlaczeniu klienta do procesu
>> programowania".
>
>moze po to, aby produkt (a nie tylko specyfikacja) optymalnie odpowiadal 
>potrzebom klienta? Zauwaz ze z jednej specyfikacji moga wyjsc zupelnie 
>rózne produkty, i z perspektywy klienta jeden bedzie dzialal lepiej, 
>drugi gorzej (np. ze wzgledu na wygode uzytkowania). Mimo ze oba przejda 
>równie dobrze "acceptance tests".

Bzines softwarowy to nie akcja dobroczynna. Projekt na odpowiadac
umowie, a nie "optymelnie zaspokajac potrzeby klienta". Klient ZAWSZE
bedzie cos chcial extra i zawsze bedzie uwazal (zwlaszcza pod koniec
projektu) ze jednak mozna by inaczej. Tyle tylko, ze ktos musi za to
placic. 

A.L.

A.L. <lewando_won_@kalabambuko.com> wrote:
> On Thu, 20 Oct 2005 16:12:26 +0100, "Bronek Kozicki" <brok@rubikon.pl>
> wrote:
>
>> A.L. <alewando@kapturek62.com> wrote:
>>> modulow ktore oferuja dosyc podsatwowa ale bogata funkcjonalnosc.
>>> Spzredawaniem zajmuje sie "sales department", a jak juz klient da
>>> sie zlapac to wkraczaja faceci od "project analysis" i robia "gap
>>> analysis" czyli okreslaja co ma byc dorobione. Potem wspolnie z
>>> klientem ustalaja "acceptance protocol" czyli kryteria na mocy
>>> ktorych klient uzna ze sprzedano mu to co zazadal. Potem to idzie do
>>> "legal department" naszego i klienta, i panowie prawnicy
>>> zatwierdzaja papiery. A na koniec naczalstwo podpisuje.
>>
>> sensowna procedura, ale przeciez nie konczy sie ona projektem. A jak
>> z tego przejsc do gotowego produktu, skoro projektu nie ma?
>>
>
> Nie robi sie projektu metoda "kota w worku". To "nowoczeste
> metodologie" sugeruja aby zaczynac kodowanie zanim sie zacznie myslec.

hę? Takich sugestii nie widziałem, ale może ja niedokładnie czytam. 
Zresztą, dalej nie odpowiedziałeś w jaki sposób ze specyfikacji bierze 
się projekt w podejściu do procesu które prezentujesz. Te "nowoczesne 
metodologie" sugerują że projekt się bierze z dodawania działających 
features do działającego i przetestowanego kodu, przy czym implementuje 
się tylko te features które są potrzebne klientowi. To złe podejście?

>>> Wiec nei wiem skad te koncepcje o "wlaczeniu klienta do procesu
>>> programowania".
>>
>> moze po to, aby produkt (a nie tylko specyfikacja) optymalnie
>> odpowiadal potrzebom klienta? Zauwaz ze z jednej specyfikacji moga
>> wyjsc zupelnie rózne produkty, i z perspektywy klienta jeden bedzie
>> dzialal lepiej, drugi gorzej (np. ze wzgledu na wygode uzytkowania).
>> Mimo ze oba przejda równie dobrze "acceptance tests".
>
> Bzines softwarowy to nie akcja dobroczynna. Projekt na odpowiadac
> umowie, a nie "optymelnie zaspokajac potrzeby klienta". Klient ZAWSZE
> bedzie cos chcial extra i zawsze bedzie uwazal (zwlaszcza pod koniec
> projektu) ze jednak mozna by inaczej. Tyle tylko, ze ktos musi za to
> placic.

no super, ale jeżeli coś można zrobić na 5 sposobów tym samym kosztem, 
to który sposób wybierzesz i dlaczego?


B.


PS. jestem nowy na tej grupie (chyba ... nie pamiętam gdzie pisałem parę 
lat temu) więc się uprzejmie witam. Programuję paręnaście lat, kocham 
żonę i dziecko i C++, Yordon się jeszcze gdzieś tam kurzy na półce 
(chyba że się go wreszcie pozbyłem), GOF się nie kurzy bo jest czytany.

 

On Thu, 20 Oct 2005 17:26:53 +0100, "Bronek Kozicki" <brok@rubikon.pl>
wrote:
 .
>
>hê? Takich sugestii nie widzia³em, ale mo¿e ja niedok³adnie czytam. 
>Zreszt±, dalej nie odpowiedzia³e¶ w jaki sposób ze specyfikacji bierze 
>siê projekt w podej¶ciu do procesu które prezentujesz. Te "nowoczesne 
>metodologie" sugeruj± ¿e projekt siê bierze z dodawania dzia³aj±cych 
>features do dzia³aj±cego i przetestowanego kodu, przy czym implementuje 
>siê tylko te features które s± potrzebne klientowi. To z³e podej¶cie?
>

Pojecie "komponentu" i "komponentyzacji" wymyslono dawno dosyc.
 
>
>no super, ale je¿eli co¶ mo¿na zrobiæ na 5 sposobów tym samym kosztem, 
>to który sposób wybierzesz i dlaczego?
>

Ten ktory dla nas najbardziej wygodny

>B.
>
>
>PS. jestem nowy na tej grupie (chyba ... nie pamiêtam gdzie pisa³em parê 
>lat temu) wiêc siê uprzejmie witam. Programujê parêna¶cie lat, kocham 
>¿onê i dziecko i C++, 


Zona i dziecko OK, z C++ nie bardzo... Proponuje pokochac cos
innego...

A.L>

A.L. wrote:
>>hê? Takich sugestii nie widzia³em, ale mo¿e ja niedok³adnie czytam. 
>>Zreszt±, dalej nie odpowiedzia³e¶ w jaki sposób ze specyfikacji bierze 
>>siê projekt w podej¶ciu do procesu które prezentujesz. Te "nowoczesne 
>>metodologie" sugeruj± ¿e projekt siê bierze z dodawania dzia³aj±cych 
>>features do dzia³aj±cego i przetestowanego kodu, przy czym implementuje 
>>siê tylko te features które s± potrzebne klientowi. To z³e podej¶cie?
> 
> Pojecie "komponentu" i "komponentyzacji" wymyslono dawno dosyc.

nie rozumiem jak to się ma do rzeczy - definiowanie features jako 
komponenty?


B.


PS. popraw proszę kodowanie. Cytujesz znaki spoza ASCII podając 
kodowanie ISO-8859-1 , a jestem pewnien że podałem ISO-8859-2