-
Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!3.eu.feeder.erj
e.net!feeder.erje.net!eternal-september.org!feeder.eternal-september.org!reader
01.eternal-september.org!.POSTED!not-for-mail
From: heby <h...@p...onet.pl>
Newsgroups: pl.misc.elektronika
Subject: Re: Microsoft Excel ;-)
Date: Thu, 18 Jul 2019 19:53:16 +0200
Organization: A noiseless patient Spider
Lines: 94
Message-ID: <qgqbmc$f6q$1@dont-email.me>
References: <5d28ea4a$0$523$65785112@news.neostrada.pl>
<1479480963$20190713141314@squadack.com>
<1...@4...net>
<2619795564$20190713232913@squadack.com> <qgg68k$auf$1@dont-email.me>
<2714917105$20190715211955@squadack.com> <qgikbr$3kp$1@dont-email.me>
<3178734552$20190716102144@squadack.com> <qgl1fb$oe9$1@dont-email.me>
<7...@g...com>
<qgmb11$9m3$1@dont-email.me>
<d...@g...com>
<qgnpmo$anl$1@dont-email.me>
<9...@g...com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 18 Jul 2019 17:53:17 -0000 (UTC)
Injection-Info: reader02.eternal-september.org;
posting-host="ca2e0f14beef25b8516c61f9d6e38dfe";
logging-data="15578";
mail-complaints-to="a...@e...org";
posting-account="U2FsdGVkX19TNtn+OWArIlIhbhg9wpST"
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
Thunderbird/60.8.0
Cancel-Lock: sha1:xX6DDtxT/no+yQMkCz/PoNqS2EE=
In-Reply-To: <9...@g...com>
Content-Language: en-US
Xref: news-archive.icm.edu.pl pl.misc.elektronika:744264
[ ukryj nagłówki ]On 18/07/2019 07:58, Dawid Rutkowski wrote:
> Jakich?
1) Moim zdaniem najważniejszy: brak pojęcia "wszystko". Zamiast tego w
typowym arkuszu znajdziesz range od:do. Czyli zamiast posługiwać się
pojęciem "zsumuj wszystkie miesiące" posługujesz się pojęciem "zsumuj
miesiące od do". Już drugi arkusz z doradztwa finansowego który dostałem
do ręki miał ten bug. Co ciekawe na niekorzyść instytucji. A co
najciekawsze, kiedy mój kolega brał kredyt rok później dostał arkusz
zupełnie inaczej wyglądający ale z tym samym bugiem, w tym samym
miejscu, w tej samej firmie. No, ale kolorki były inne ... a buga
zgłosiłem i jak widać wyszło jak zwykle czyli kontrole wersji uzyskuje
się poprzez jej nieuzyskiwanie bo się nie da
2) Wklejenie czegoś komórkę niżej oznacza problem z punktu 1). Efektem
czego wiargodność wyniku wymaga precyzji nieosiągalnej dla białka po 8h
gapienia się w tabelki. Wisiała kiedyś lista studentów ze stypendiami na
pewnej prywatnej uczelni. Przesunięta o jeden wiersz. I niestety wypłaty
na konto tez były przesunięte ...
3) Pisanie formuł to tak naprawdę cieżkie programowanie czegoś z okolic
lambd. Sekretarki tego nie potrafią. Efekt: po mniej więcej pół roku
obiegu pewnego arkusza część formuł została przerobiona na stałe.
Dowiedziałem się od pewnej księgowej "że tak jest łatwiej coś zmienić
tylko trzeba pamiętać żeby ..."
4) Ukrywanie algorytmiki. W zasadzie nie da się rozsądnie wygenerować
ścieżki obliczeniowej w dużym arkuszu. Szukanie buga jest mordęgą
ponieważ arkusz zasłania tak naprawdę algorytmikę i utrudnia do niej
dostęp recukujac formuły do liczb i uniemożliwiając wygodnie śledzenie
flow obliczeniowego.
5) Brak prawdziwego współdzielenia danych. Arkusze to najzwyczajniej
miliardy copy-paste z innych arkuszy o niejasnym stanie spójności danych
akumulując błędy. Pamiętam panikę w pewnej instytucji kiedy jeden z
oddziałów zmienił nazwę i było "a ze sto chyba" arkuszy do przerobienia.
6) Udawanie że trudne rzeczy można łatwo osiągnąć. Na przykład taki
solver. Rachu ciachu i liczy magicznie gdzie się opłaca kupić taniej
kaszę. Tylko że praktycznie nikt z księgowych nie wie jak działa. Efektm
czego działa przypadkowo. Swego czasu widziałem sporą hurtownię
organizującą zakupy pod kątem logistyki wlasnie na arkuszu z solverem.
Wychodziły bzdury do czasu aż ktoś na kalkulatorze nie pokazał że nie
znajduje najlepszej oferty tylko jakąś przypadkową. Ponad pół roku nie
zauważyli. Komputery się nie mylą.
7) Brak typowości. Arkusz łyknie tak samo łatwo puste pole jak "0" choć
powinno to spowodować błąd przy arytmetyce. Typy pól to tylko taka
wizualizacja. Wiele starych arkuszy potrafi dodać 29 sierpnia do "dupa"
i podzielić przez 13.5. I dostać wynik. I co ważne to jest potrzebne,
jak się dowiedziałem od pewnego sentymetalnie nastawionego nauczyciela
wspominającego bodaj Lotusa z okolic MS-DOSa.
8) Brak oddzielenia algorytmu od danych. Wszystko na kupie łacznie z
wizualizacją kolorowych kresek. Ludzie od antywzorców projektowych
dostają biegunki na samą myśl.
9) Tendencja do akumulacji błędów. Ponieważ nowy arkusz powstaje prawie
na pewno ze starego arkusza to i błędy się akumulują. To raczej
charakterystyczne problemy zarządzania danymi przez pliki a nie
dedykowane narzędzie jak db
10) Udawanie profesjonalnej bazy danych w sytuacji gdy to jest tylko
gówniane narzedzie do rysowania wykresów na laborki. Miałem okazję
ogladać duży arkusz gdzie ktoś zadał sobie trud zorganizowania go jak
bazę danych z indeksami itp. I nie wiadomo po co. Najzwyczajniej. Nie
wiadomo.
11) Kiepskie przystosowanie do obliczeń finansowych, enkodowanie binarne
floating pointów tutaj nie pomaga, nowe koncpecje nie potrafią się
przebić bo nikt z zainteresowanych nie pojmuje w ogóle o co chodzi.
12) Mit że księgowa dostaje arkusz excela i tylko wklepuje dane. Nie, w
wyniku zwykłych błedów białkowych arkusz taki ulega degradacji i ciężko
to stwierdzić gapiąc się tylko na wyniki że gdzieś ktoś skasował formułe
lub zrobił inne kuku. Wszystkie do tej pory arkusze jakie miałem w
rękach miały albo niezabezpieczone algorytmy przed ingerencją albo
zabezpieczone tylko niewielką część jak się komuś przypomniało że
trzeba. Na kretaywność księgowych ogólnie zabezpieczenia nie ma. Arkusz
przypomina odbezpieczony granat zlepiony gumą do zucia.
Oczywiscie można zabezpieczyć arkusze w lepszy lub gorszy sposób. Ale
takie przykłady pokazują że *ABSOLUTNIE* nikt tego nie robi, nawet jesli
to miało by kosztować miliardy dolców strat to dalej cieżko sobie
wyobrazić śrubki bez młotków do wkręcania:
https://www.forbes.com/sites/timworstall/2013/02/13/
microsofts-excel-might-be-the-most-dangerous-softwar
e-on-the-planet/#4108466a633d
Istnieje powszechny mit że komputery liczą dobrze i można im zaufać.
Nikt nie widzi ton białka które te komputery używają jako input do
danych i algorytmów. I to białka często skrajnie tępego technicznie w
przypadku excela dostającego do ręki cholernie niebezpieczne narzędzie
decydujące o miliardach dolców.
Następne wpisy z tego wątku
- 19.07.19 08:16 mk
- 19.07.19 11:33 Dawid Rutkowski
- 19.07.19 11:34 Dawid Rutkowski
- 20.07.19 21:38 mk
- 20.07.19 21:53 Piotr Wyderski
- 20.07.19 22:01 Piotr Wyderski
- 20.07.19 22:10 Piotr Wyderski
- 20.07.19 22:40 Jarosław Sokołowski
- 21.07.19 08:21 Piotr Wyderski
- 21.07.19 11:20 J.F.
- 21.07.19 13:27 Zbych
- 21.07.19 19:08 Dawid Rutkowski
- 21.07.19 19:25 Mateusz Viste
- 21.07.19 21:24 Dawid Rutkowski
- 21.07.19 22:30 heby
Najnowsze wątki z tej grupy
- SEP 1 kV E
- Aku LiPo źródło dostaw - ktoś poleci ?
- starość nie radość
- Ataki hakerskie
- Akumulatorki Ni-MH AA i AAA Green Cell
- Dławik CM
- JDG i utylizacja sprzetu
- Identyfikacja układ SO8 w sterowniku migających światełek choinkowych
- DS1813-10 się psuje
- Taki tam szkolny problem...
- LIR2032 a ML2032
- SmartWatch Multimetr bezprzewodowy
- olej psuje?
- Internet w lesie - Starlink
- Opis produktu z Aliexpress
Najnowsze wątki
- 2024-12-12 Warszawa => Administrator Bezpieczeństwa IT <=
- 2024-12-12 Ostrów Wielkopolski => Trener zespołu sprzedaży Call Center <=
- 2024-12-12 Kraków => Key Account Manager <=
- 2024-12-11 SEP 1 kV E
- 2024-12-11 DNS restrictions are on
- 2024-12-11 wielkie bu
- 2024-12-11 Białystok => Inżynier bezpieczeństwa aplikacji <=
- 2024-12-11 Aku LiPo źródło dostaw - ktoś poleci ?
- 2024-12-11 Warszawa => Specjalista Bezpieczeństwa Informacji <=
- 2024-12-11 Wrocław => Application Security Engineer <=
- 2024-12-11 Warszawa => Analyst in the Trade Development department (experience wi
- 2024-12-11 Lublin => Programista Delphi <=
- 2024-12-11 Motodziennik #305 Nowy ELEKTRYK za 350 złotych miesięcznie? Kreatywne kredytowanie problemów
- 2024-12-11 Warszawa => Spedytor Międzynarodowy <=
- 2024-12-11 Katowice => Key Account Manager (ERP) <=