Příspěvky

16

Vývoj / Re:Má smysl učit se Pascal (Delphi)?

« kdy: 11. 06. 2019, 17:37:47 »

Projekty Lazarus a Free Pascal jsou živé, takže učit se to stále dá.

Delphi jako takové stále existuje. Jenže:

1. Je drahé. Vyjde zhruba na dvojnásobek Visual Studia a nemá žádnou komerční verzi zdarma. Takže každý, kdo bude potřebovat koukat do zdrojáků nebo je kompilovat, musí mít placenou licenci. To dnes už není zvykem, projekty psané ve Visual Studiu dnes můžete přeložit i zdarma.
2. Mají hodně zvláštní politiku nových verzí - s novou verzí se vždycky něco rozbije. Člověk si z jiných jazyků už zvykl na zpětnou kompatibilitu. Tady se na ní nehledí, respektive "to be as compatible as possible".
3. Úplná katastrofa je stav knihoven. Například pro Oracle mají hned dvě, ale každá něco neumí. A na dokumentaci čas nezbyl. Druhá věc je, že do nich nedávají nové věci dostatečně rychle. Například Oracle od verze 12.2 umí v SQL VARCHAR2 až o velikosti 32k. Jenže jakmile to zapnete, tak vám aplikace přestane fungovat, protože knihovna s tím nepočítá a všude cpe default 4000 bytů.

Učit se na tom dá. Ale komerční produkt bych na tom už nestavěl. A když už, tak Free Pascal a Lazarus. Na Delphi zapomeňte, to je dnes těžká rýžovačka na firmy, které stále ještě nezvládly přepsat své legacy věci do něčeho přívětivějšího. Mají příliš malý tým, než aby to udrželi plně funkční včetně knihoven.

17

Vývoj / Re:Utilita YACC

« kdy: 21. 05. 2019, 13:09:21 »

...
Jinak spis nez Yacc doporucuju pouzivat ANTLR a sousivejici materialy (maji je na webu).

U nás jsme na ANTLR přešli komplet před cca dvěma lety. Jsou tam tři chytáky:

1. Je to LL. Pokud tazatel už má hotovou gramatiku ve verzi pro YACC (který je LALR), tak bude muset investovat trochu času do přepsání pro ANTLR. Pokud se jedná o hodně jednoduchý DSL, tak by té práce nemělo být hodně.

2. ANTLR má vlastní lexer. A nám se moc nepodařilo ho přesvědčit, aby ho nechtěl. Vzdali jsme to zejména proto, že jeho lexer je vlastně hodně silný. Napsat pravidla pro něj nakonec bylo docela triviální.

3. ANTLR není určen k tomu, aby překládal. Do gramatiky se nepíší instrukce o tom, co se má zapsat na výstup. Styl práce je v tom, že vám ANTLR parsuje vstup a vytváří parse tree. To můžete ihned procházet přes visitora nebo později přes listener. Je to trochu jiný styl práce než YACC, protože si musíte přímo napsat kód, který bude řešit "vstoupil jsem do terminálu WHILE, co s tím?"

Přijde mi, že to je docela dost odlišností od YACC. S ohledem na původní dotaz nejspíš až příliš.

Já přechodu na ANTLR nelituji, ale jednoduché to nebylo. Používáme to třebas na parsování PL/SQL - generuje nám to komplet dokumentaci včetně referencí odkud je co voláno, kde co z čeho čte, co mění a co zapisuje, syntax highlighted převod do HTML apod. Času a práce je v tom utopeno hodně, ale ANTLR v tom pomohl.

18

Vývoj / Re:Návrh relační databáze

« kdy: 25. 04. 2019, 14:36:51 »

Řešili, několikrát. Používáme tyto tři šablony:

1. Item Extension Codes

A. Máme tabulku položek, kde jsou její základní údaje (branch plant, item number, item description, item type, gl class atd.)
B. A pak máme tabulku "Item Extension Codes", která má PK stejný jako ta první. V té máme cca 120 sloupců pojmenovaných stylem "number01, number02, date01, date02, text01,..."
C. Další tabulka je tabulka IID. Má sloupce Branch Plant, IID Key, IID Value a IID Description. Typický záznam je Branch Plant 728 (Brno), IID Key VPRODTYPE, IID Value "S2", IID Description "NHP SAS 2.5 10K"
D. A nakonec existuje tabulka "Extension Code Definition", kde je primárním klíčem Branch Plant, Item Type a FieldName. Další sloupec je Description, příznak Mandatory a IID Key. Do té se při nastavování databáze třebas napíše, že pro Branch Plant 728 (Brno) a Item Type IM (vyráběná položka) se sloupec "text05" jmenuje "Vendor Product Type", Mandatory má nastaveno na "yes" a IID klíč je "VPRODTYPE".

Celé to pak funguje tak, že založím položku v první tabulce. Do té druhé můžu ale nemusím. Pro tu druhou funguje formulář tak, že je tam tuším na třech záložkách až stovky políček. Systém sám podle tabulky z bodu D ví, které zobrazit (mají mandatory yes nebo no) a které ne (nemají záznam nebo mají mandatory disabled). Z tabulky D pak i nastaví správný popisek daného pole. Takže pro každý typ položky (nakupovaná, vyráběná, polotovar, fiktivní atd.) se zobrazí jen ta pole, která sleduji. Tabulka C se pak používá na kontrolu zadaných hodnot - pokud tabulka D specifikuje nějaký klíč, tak se zaprvé uživateli nabízí seznam hodnot a zadruhé se ověřuje, že vybral některou z nich.

Přidat nový atribut je pak o tom najít si pro danou pobočku a typ položky dosud nepoužité pole a udělat pro něj záznam do tabulky D.

2. Item Cross References

A. Máme tabulku položek, kde jsou její základní údaje (branch plant, item number, item description, item type, gl class atd.)
B. Mámě tabulku Item Cross Reference Type. Primární klíč je XType. Jediný další je sloupeček Description. Hodnoty typu VP = Vendor Part Number, EM = Customer Model Number atd.
C. A finálně tabulka Item Cross Reference, kde primární klíč je Item Number, Address Number a XType.

Do tabulky A se vkládají položky. Ke každé je pak možné do tabulky C přiřadit další údaje. Tím, že je v tabulce C v primárním klíči i Address Number, tak můžete mít jeden údaj (například Customer Part Number) pro různé address booky jiný. Address Book je typicky ID zákazníka, ID dodavatele, ID nákupčího apod. Takže když někomu dodáte svou položku 3731052, tak mu můžete na dodací list napsat číslo, jaké chce on. Což je docela běžné, že stálí zákazníci chtějí objednávat podle jejich čísla položky. A pokud jednu položku dodáváte více zákazníkům, tak se vám tahle vlastnost tabulky C dost hodí.

3. Kaskáda tabulek

A. Máme základní tabulku, například Transaction. Primární klíč ID transakce. Další sloupce typu datum transakce, účetní datum, typ transakce, celková částka atd.
B. K ní máme další tabulku, například InventoryTransaction. Primární klíč je stále to samé ID transakce a má FK na tabulku Transaction. Přidává další sloupce typu Item Number, Quantity, Unit of Measure, Branch Plant atd.
C. A máme i jinou tabulku, například PaymentTransaction. Primární klíč stále to samé ID transakce a opět FK na Transaction. Přidává sloupce typu VAT Code, Net Amount, atd.
D. A ještě jiná tabulka pro EventTransaction. Klíč stále stejný a opět FK na Transaction. Navíc sloupce jako EventId, EntryType, AuthorizationMethod atd.

Každá transakce je pak v tabulce A s tím, že dodatečné údaje má v některé z dalších tabulek podle typu transakce. Tohle se používá ve chvíli, kdy mám několik typů daného objektu, které ale znám už ve fázi návrhu. Výhoda je v tom, že všechny sloupce můžete hezky navázat přes foreign key a obecně se s tím dělá trochu lépe.

--- Co vybrat ---

Metoda 1 je docela snadná na implementaci a dělá se k ní i hezké uživatelské rozhraní. Dobře se pro to píší sestavy. Blbě se s tím ale dělá cokoliv obecného. Do té míry, že vám sestava pro Brno nebude fungovat v Ploveru, protože tam mají stejný údaj v jiném sloupci, protože ten původní už roky používali pro jiného zákazníka.

Metoda 2 má výhodu v tom, že k jedné položce nejen že máte libovolný počet dodatečných údajů, ale dokonce pro každého zákazníka/dodavatele jinou hodnotu. Hůř se proto ale dělá uživatelské rozhraní - zaprvé nevíte který z definovaných 84 typů Cross Reference máte nabídnout, zadruhé z toho hezké okénko neuděláte už proto, že dopředu nevíte pro kolik různých zákazníků uživatel bude chtít vyplnit End Customer Model Number.

Metoda 3 je velmi jednoduchá na implementaci. Vše je předem dáno a vy si můžete snadno vytvářet formuláře, sestavy, integritní omezení apod. Nevýhoda je v tom, že za běhu už nic nezměníte. A skrytá nevýhoda je v tom, že se vám v průběhu let začnou vývojáři v té kaskádě tabulek ztrácet a budou mít tendenci to lepit novými tabulkami.

Všechny mají výhodu v tom, že máte jednu tabulku A, kde máte definované všechny položky/transakce apod. Základ formuláře nebo sestavy tedy má jediný zdroj, jedinou tabulku. Stejně tak tabulky typu kusovník se budou odkazovat přes FK právě do tabulky A. Jediné, co si pak musíte dolepit jinak, jsou dodatečné informace.

19

Vývoj / Re:Jak je to s kompilací

« kdy: 24. 04. 2019, 11:03:56 »

Jde o to, co kompilujete. Pojďme se podívat 30 let zpátky a programujme hru pro počítač Commodore Amiga. Máme na výběr několik jazyků, ale to není zajímavé. Zajímavé je, že máme na výběr, co bude výsledkem.

V téhle době je nejčastější volbou "binární image". Výsledkem je tedy posloupnost bytů, které se zapíší na disketu. Po startu počítače se načte základ OS z ROM. Z něj je zajímavá jediná věc - a sice že "olizuje" disketovou mechaniku a čeká, zda do ní někdo nějakou disketu vsune. Pokud ano, pak z ní načte první sektor do RAM a zkusí ho spustit jako binární kód.

Při výrobě diskety je tedy potřeba napsat si zavaděč, který se umístí na disketu. Ten si naprogramujeme třebas tak, že načte prvních 150KB z diskety, uloží je od adresy RAM 250000 a skočí na začátek. Ten zavaděč i těch 150KB je potřeba na disketu nějak zapsat, ale na to je celá řada programů. První chyták - nejsou to soubory. Nemáme žádný OS, který by tušil, co na disketě je. Pomocí obslužných rutin v ROM skutečně čteme konkrétní stopy a bloky, nikoliv soubory.

Vyrobit těch 150KB pak obnáší napsat si ten program, překladači říci, že bude uložen na adrese 250000 a nechat ho přeložit. Při psaní jste na tom jako s tím zavaděčem - máte jen základní ovládací rutiny v ROM. A v nich není skoro nic. Takže pokud chcete zobrazit černou obrazovku a uprostřed ní bílý kruh, pak si musíte nastudovat jak se ovládá grafický koprocesor. A hezky ručně mu nastavit hodnotu registrů, vygenerovat si bitmapu, nastrkat na správné místo v paměti a máte hotovo. Potřebujete přehrát zvuk? Tak opět příručku ke zvukovému koprocesoru a to dáte. Potřebujete něco složitějšího, například nakreslit na obrazovku okénko a kurzor, který jde ovládat myší? No tak jak se ovládá grafický koprocesor už víte, jak vytvářet bitmapovou grafiku si už nastudujete snadno. No a myš je snadná, je mapovaná na nějaké HW porty, tak si opět jen nastudujete na jaké a jak s ní komunikovat.

No a když už vám to funguje na vašem počítači, tak je čas začít řešit počítače jiné. Ty mohou mít více disketových mechanik a tak musíte zjistit, ve které vlastně vaše disketa je. A pak číst z té správné, nebo se prostě jen kousnout s chybou "sorry jako ale tohle jde spustit jen z FD0". A co více myší? Nebo jinak rozložená paměť? Chip RAM vs FAST RAM, aneb konflikt Amiga 500+ vs Amiga 500 + RAM modul.

Taková perlička, co některým na první pohled nedochází - na počítači běží váš program. Jen a pouze váš program. Jak doběhne, tak se počítač rebootuje a pak je možné spustit nějaký jiný program.


No, tak to máme "kompilujeme jako binární kód pro počítač". Nyní si proberem "kompilujeme jako spustitelný program pro operační systém". Vaše situace je v mnohém lepší - OS vám nabízí rovnou celou škálu ovladačů. Už nemusíte studovat jak ovládat konkrétní HW. A nemusíte ani studovat, jaký HW vlastně máte. Ani o natažení do paměti se starat nemusíte, to OS udělá za vás, včetně relokace programu na volnou adresu. I s tou disketou je práce rázem snadnější, protože váš program je soubor! A co víc, vy si můžete na disketu dát souborů víc a váš program si je pak za běhu může volně číst! Stačí mu k tomu znát název souboru, vůbec nemusí řešit na kterém bloku začíná a na kterém končí.

Co dál vám OS nabídnul? Třebas GUI! Nemusíte si programovat vlastní ovladač, vlastní rasterizaci, generování bitmap apod. Prostě jen zavoláte funkci OS a rázem máte na obrazovce okénko. Luxus! A co víc, tím okénkem jde hýbat, jde zvětšit, zmenšit, minimalizovat. A to vše bez nutnosti si to naprogramovat. A víte co? Těch oken je na obrazovce více a dokonce i z jiných programů! Vážně, už tam nejste sám.

Ale má to i stinné stránky. Najednou si nemůžete dělat co chcete a musíte respektovat pravidla. Když potřebujete kus RAM, tak si řeknete OS a on vám řekne kde a kolik jí máte k dispozici. Úleva je v tom, že si nemusíte z HW zjišťovat kolik a kde je RAM a pak si sledovat její využití. Přítěž v tom, že si nemůžete jen tak říci kde ji chcete mít a navíc ani tu RAM nemusíte dostat - buď už není dost volné pro vás, nebo (častěji) není volný takový kus v celku.

----

A teď do současnosti. Programy prvního typu se dnes prakticky nepíší. Když budete chtít pár příkladů, tak LILO, GRUB nebo VMware ESXi. Vy ale takový program psát nebudete, protože je to nad vaše síly. A navíc by to uživatele dost iritovalo - málokdo by dneska chtěl rebootovat jen proto, aby spustil váš program.

Prakticky vše je dnes ten druhý případ, spustitelný soubor pro nějaký OS. Ten soubor začíná instrukcemi pro OS. Tedy jaké části toho souboru vzít a kam je nakopírovat. Pak adresu, na kterou se má převést řízení. OS podle instrukcí vytvoří proces, zarezervuje RAM, vykopíruje kusy souboru na správné místo a nakonec zavolá ten binární kód. Samotný program pak, podle konvencí OS, volá služby OS. Dříve se to řešilo třebas tabulkou přerušení - do registrů jste napsal co potřebujete a vyvolal přerušení, na což zareagoval procesor přechodem do módu supervizoru a vyvolal obsluhu přerušení, což byla součást OS. Dnes se to prakticky vždy řeší tím, že ve vašem programu použijete nějakou hotovou knihovnu, například libc. Takže pro váš program je to defakto jen volání funkce. Co se děje na pozadí a jak vlastně k volání OS dojde už vás nezajímá. To za vás udělá ta knihovna. Jenže právě ta je v každém OS jiná. Win32, msvcrt.dll, libc, glibc atd.

Koukněte se sem:
https://wiki.osdev.org/VGA_Hardware
https://files.osdev.org/mirrors/geezer/osd/graphics/modes.c

A pak si upřímně odpovězte na otázku, zda by se vám tohle chtělo programovat, nebo to raději necháte na OS a jeho ovladačích?

20

Odkladiště / Re:Je vyvážení bílé určeno trojicí nebo maticí?

« kdy: 18. 04. 2019, 12:26:18 »

Je potřeba neplést vyvážení bílé a transformaci do jiného barevného prostoru.
...

Aby se to trochu více pletlo, tak matematický aparát to má oboje prakticky stejný. Takže se vám na první pohled všude objeví matice 3x3. Teprve na ten druhý si všimnete, že v případě vyvážení bílé tam jsou nenulové prvky jen na diagonále. Tedy tři. Je to tak proto, že matematici nemají definovanou operaci, která by vám očekávaným způsobem vynásobila dva vektory a vracela opět vektor. Skalární součin vrací jednu hodnotu a vektorový součin sice vrací vektor, ale vynásobí vám mezi sebou prvky úplně jinak, než tady potřebujete. Proto i u vyvážení bílé bude ta matice 3x3, ovšem jen se třemi nenulovými prvky. Praktická realizace s maticí nepracuje, tam prostě jen vynásobíte r*c1, g*c2, b*c3.

Zkrátka, matematici vám tam tu matici 3x3 napíší i u vyvážení bílé. Teprve pohled na prvky té matice vám prozradí, jak to je ve skutečnosti.

21

Software / Re:VMware Workstation a Player

« kdy: 13. 03. 2019, 15:19:12 »

A kde mohu najít správné nastavení tohoto programu/virtuálního OS? Je v tomto ohledu omezená free verze, je potřeba verzi Pro?

Takže se nemohu spoléhat na to, že si na VOS vyzkouším zavirovaný program, který, pokud nyní takto zavirovaný VOS smažu, nezůstane to bez následků pro můj originální OS/síť... K čemu potom tento program slouží, když ne na "testování"? Četl jsem, že lze na takto vytvořený VOS nějaký vir spustit a sledovat, jak se chová a co páchá, ale pokud by to poškodilo samotný PC či jeho přídavné zařízení, neoplatí se to.

Free verze na to stačí. Ale bude to docela otrava, protože právě na tohle se hodně hodí snapshoty, které v Playeru nejsou. Snapshot je uložený stav. Uložte si jich kolik chcete a kdykoliv se k nim vracejte. Což je fajn právě při testování - jakmile mám otestováno tak se mohu vrátit do původní stavu a testovat něco jiného.

Co se virů týká, tak ano, takhle testovat jdou. Váš hostitelský OS je v bezpečí a nepoznamenán. ALE. Jsou tam chytáky:

1. Nepovolte té virtuálce přístup na síť (dejte Host-only nebo Custom). Viry dnes obvykle začnou útočit na všechna zařízení v lokální síti. Vy pak sice zavirovanou virtuálku vypnete a smažete, jenže to už vám může sedět breberka v tiskárně, routeru, kameře nebo jiném PC.

2. Bacha na VMWare tools a co si jak nasdílíte. Na internetu se občas narazí na návod, kde si mapují adresáře nebo rovnou celé disky z hostitelského OS do virtuálky. Virtuálka vám pak sice nemůže napadnout hostitelský OS, ale pořád vám může třebas zaheslovat nebo zavirovat soubory, které jste do ní nasdílel.

3. Pokud je hostitelský OS z rodiny Microsoft Windows, tak riskujete, že vám ta virtuálka přeci jen dokáže utéct. Ne že by byla chyba ve VMWare, ale jde o to, že virtuálka může po síti útočit na vlastní host OS. A tam je holt problém, že Windows mají velmi často nějaké známé a dosud neopravené chyby. Je to vlastně variace na bod 1 - vir vám běží na virtuálním PC, které má na to vaše skutečné přímou linku. A ruku na sdrce, v konfiguraci firewallu občas bývají docela šílené věci pro lokální síť. Bez přístupu VM na síť a bez nainstalovaných VMWare tools jste v bezpečí.

4. V zásadě najdete jen hodně hloupé viry. Takové ty milionté variace na něco profláklého, co vám odchytí antivir na první pokus. Chytré viry dělají věci, které vám ten test zkomplikují. Kupříkladu se neprojevují hned, ale klidně hodiny čekají. Případně si otestují, zda je dostupná síť - pokud ne, tak se ihned vypnou. Další věc je test na to, zda běží ve virtuálce - pokud zjistí, že ano (například díky VMWare tools), tak se také ihned vypnou. Případně test na instalovaný HW: podezřele málo jader CPU? RAM není násobkem 1GB? Je tam grafická karta? Odpovídá integrovaná grafická karta parametrům CPU? Jaké je rozlišení obrazovky? A hodně se zjistí i z obsahu clipboardu, adresáře temp, časových známek souborů OS atd. Zkrátka viry mají docela dost vodítek jak zjistit, zda běží "na ostro" nebo zda je někdo naopak jen zkoumá a pozoruje. V důsledku tak můžete mít zavirovaný program, který se ve virtuálce tváří naprosto v pohodě a nic špatného nedělá, ale po instalaci do hlavního OS se začnou dít hrozné věci.

Osobně tedy nedoporučuji podezřelé programy testovat ve virtuálce. Zejména kvůli bodům 2 a 4. To už je lepší podezřelý program ve virtuálce prostě provozovat. Normálně ho tam mít a používat. Ale ani to není bez rizika, dráždíte hada bosou nohou a ten vám může v nestřeženou chvíli třebas změnit obsah clipboardu.

22

/dev/null / Re:Jak se naučit výborně anglicky?

« kdy: 27. 02. 2019, 12:14:45 »

Já si angličtinou na střední taky prošel, ale rozhodně jsem se nijak špičkově nenaučil. V mém okolí lidé také ne, ale například premiér anglicky mluví dobře a vyjednává v EU kšefty pro ČR, tak ten se to taky někde musel naučit. Takže je to otázka peněz, dobré kurzy budou, ale budou něco stát.

Ne, neumí špičkově anglicky. Nikdo nemluví špičkově anglicky, ani rodilí mluvčí. Prostě proto, že není jedna jediná angličtina. Pokud jste někdy byl na jednání irů, skotů a američanů, tak jste se musel divit a smát. A když sáhnete po národnostech jako jsou němci, holanďané nebo francouzi, tak to co národ to unikátní názor na mluvenou angličtinu.

Proto platí poměrně jednoduché: čtěte anglickou literaturu, pište, mluvte. A také poslouchejte, ale to je na tom to nejtěžší. Základ je ta psaná angličtina, ta je víceméně všude stejná. A nikdo (snad kromě čechů) nebude řešit "color" vs "colour". Mluvená je trabl, protože tam má každý jiný přízvuk. Kdysi při jednání s lidmi z HP to vzdali i naši kolegové z USA a raději se přešlo na psaní do chatu, protože ten skot měl přízvuk, který jsme nikdo nedal.

Nebojte se angličtiny. Prostě ji začněte používat. A neřešte jak dobrá zrovna ta vaše je. I kdybyste vystudoval tu "nejsprávnější" angličtinu, která se vyučuje v Egyptě na univerzitě v Cairo (bývalá britská kolonie, asi jediná kde stále udržují originální britskou angličtinu), tak to nic nezmění. Stejně budete mít problém rozumět polovině světa a polovina světa bude těžko rozumět vám. Problémy s "pakidž" vs "pekidž" zkrátka řeší i rodilí mluvčí.

Co je dobré ke zlepšení angličtiny je přijmout jejich stavbu vět. Krátké. Žádná rozvitá souvětí, žádné dvojté negace. Pořadím slov lze sice něco zdůraznit, ale to je už cesta do pekla, protože to angličan může chápat jinak než američan. Omezit používání záporů a negací tak nějak obecně: místo "can't be skipped" použít třebas "must be done", místo "is not open" napsat prostě "is closed" atd. Přijmout jejich mentalitu, že čárka v souvětí odděluje dvě věty, nikoliv že je spojuje. Takže oblíbené české "v první větě tvrdíme něco o něčem, ale pak napíšeme "ale" a popřeme to" je další cesta do pekla nedorozumění. První větu pojmou jako daný fakt a druhou budou ignorovat, protože jim nedává smysl. Ono to české oblíbené "ale" se sice překládá jako "but", ale oni ho tak nepoužívají. Když už potřebují něco vynegovat, tak ne spojkou ve druhé větě, ale začnou už tu první stylem "despite XY".

A hlavně neřeště, čí angličtina je lepší. Každý národ jí má trochu jinou. A vy budete poměrně často jednat anglicky s národem, kde angličtina není úřední jazyk - s němci, číňany, švédy, indy, švícary atd.

Pokud hledáte kurzy, tak se koukněte po nějakém, kde vás oficiálně připraví třebas na TOEFL. Na peníze docela drahé, trvá to pár let, ale nakonec si můžete udělat oficiální papír, že umíte anglicky (podle amerických standardů). Obdobně můžete zvolit FCE, což je britská angličtina. České státnice z angličtiny jsou dobré leda tak když to po vás bude chtít český zaměstnavatel, nebo na to budete chtít razítko (kupříkladu překládat právní dokumenty). V zahraničí vám ji neuznají, tam když už budou něco chtít, tak právě TOEFL nebo FCE/CAE/CPE, případně IELTS (když budete chtít studovat na univerzitě v Británii).

23

Sítě / Re:Levné SIM karty pro IoT

« kdy: 19. 02. 2019, 14:49:01 »

Co vymýšlíte za blbosti? Prostě si to objednejte na sebe, v čem je problém?!

Ne každý má firmu. A tohle je nabídka jen pro firmy. Sice by si člověk mohl nějakou vymyslet, jenže to asi u karty "500 MB na 10 let" riskovat nechcete.