IT pro otrlé

[York]

Všechno možné, vesměs nějaká komunikace tam a zpět s větší populací zaměstnanců, která je nějakým způsobem prediktabilní, ale příliš složitá na různé merge maily, tj. poslat třeba 2000 lidí komunikaci, která je upravená podle jeho osobní situace, kterou známe, a na což očekáváme nějak prediktabilní, ale velmi různorodou reakci, kterou chceme automaticky zpracovat.

To mi zní jako nějaký webový formulář.

(třeba nedebilní správa docházky a dovolených)

Na to určitě aplikace existujou, rozhodně bych to nepsal znova.

Já bych třeba měl strašně rád něco, co připraví novému zaměstnanci počítač bez nějakých extra lidských zásahů

Tohle se dělá deploynutím připraveného image. Nikdy jsem to ale nedělal, takže podrobnosti ti neřeknu.

[Sosacek]

On Eleshar chce obchazet prikazane oficialni aplikace, ne to udelat spravne od zacatku - to nejspis nesmi, kvuli korporatni korupci a politice.

Treba ten image stoprocentne dela it, a typek chce zmeny proti imidzi, pac jiny ho nenechaji udelat.

[Alef0]

Jo inak: deployment pre nových používateľov sa úplne bežne rieši cez image: pri bootovaní mašiny sa bootne zo siete a nahodí sa komplet nové prostredie. Ono každý správca siete / systémov príde na to, že po 5 inštalácii Windowsu mu prepne v mozgu a ide si to zautomatizovať.

[Vallun]

Jo, to mohu potvrdit, to nějak funguje dokonce i u nás ve státním:)

Lze někde získat představu co umí kvalitní moderní spisová služba?

Chci toho moc, když mám představu, že by mei dokuemnty doručenými datovkou rozpoznala nějaké určité (předem docela jasně definované) a prioritizovala je? nebo dokonce dokázala hlídat změny stavu v databázi jsutice.cz?

[York]

Chci toho moc, když mám představu, že by mei dokuemnty doručenými datovkou rozpoznala nějaké určité (předem docela jasně definované) a prioritizovala je? nebo dokonce dokázala hlídat změny stavu v databázi jsutice.cz?

Nevím, co uměj existující aplikace, ale všechno, co píšeš, v pohodě umět můžou. U rozpoznávání dokumentů je teda problém s formáty - většinou se to řeší tak, že se k dokumentu přibalí metadata, podle kterých pak děláš takovéhle filtrování. Hlídat změny stavu databáze není problém, pokud ta databáze vystavuje změny stavu přes nějaké API. V knihovnictví a archivnictví se na to například používá protokol OAI-PMH.

[midewiwin]

Správa docházky je debilní vždycky. Někteří šéfové z ní samozřejmě dokážou udělat debilní záležitost na entou.
Takhle by to šlo:

A už zas prchám z tohoto sletu čarodějů do relativního bezpečí.

[Vallun]

Docházku zvldá slušně SAP, jen je drahej a musí se umět nastavit...u nás to sntavení trvalo 4 roky

[Eleshar_Vermillion]

On Eleshar chce obchazet prikazane oficialni aplikace, ne to udelat spravne od zacatku - to nejspis nesmi, kvuli korporatni korupci a politice.

Treba ten image stoprocentne dela it, a typek chce zmeny proti imidzi, pac jiny ho nenechaji udelat.

V podstatě tak, přesněji jde o to, že máme jeden image na organisaci o 500 lidí s asi 30 odděleními, z nichž skoro každé potřebuje nějaké trochu jiné věci (já jich mám poměrně dost, protože mě zajímá, jestli moji lidi dělají efektivně).

Za změnu existujícího image by nám IT naúčtovalo třeba pár set tisíc (jakože fakt) a 2 roky by to schvaloval jejich management (2 roky proto, že by se to muselo proeskaloval k CIO, jinak by nám to neschválili nikdy, protože by se tím připravovali o jednotlivé service requesty, za které nám samozřejmě učtují), takže se to krom nějakých úprav v registrech dělá všechno ručně.

[Sosacek]

S dochazkou a dovolenou to predpokladam bude stejne, co.

To je tezky.

[Eleshar_Vermillion]

Docházka je v pohodě. Na tu samozřejmě máme robustní systém mzdové účtárny (jeden z modulů SAPu) a původní problém, kdy se docházkové listy posílaly mailem a schvalovaly mailem, se vyřešil přes robustní UserForm v Excelu (přesně nevím, jak funguje, neměl jsem s tím nic společného). Dovolená se dá řešit v rámci tohoto systému spolu s nějakým procesem schvalování.

U toho všeho je ale cítit, že je to tak trochu vojeb, už jen proto, že všechny tyhle "aplikace" jsou ve skutečnosti pluginy v Excelu, takže já tak jako zkouším přemýšlet o alternativách s tím, že bych se třeba i něco jako bokem naučil a byl připraven na dobu, až moji faktickou práci za těch 5-10 let budou chtít outsourcovat z Indie (a aby až to tam přesunou, zjistili, že na všechny věci potřebují ve skutečnosti nikoliv 2x, nýbrž 30x tolik lidí, protože z těch automatisací neuvidí ani řádku ).

[Pieta]

Říkal někdo IT pro otrlé? (:

SQL je/není programovací jazyk

Podle mě je to taková schrödingerovina - postupy v sql se dost volně přelévají mezi jasným algoritmem a ne moc algoritmem, podle toho, jaký problém zrovna řešíš, a jak moc při práci využíváš nějaké procedurální nadstavby. Jednu chvíli je to "prostě mi vrať data, která splňují tuhle řadu podmínek", hned na to "a v lese postupuj od listů ke kořenům a iteruj operaci X".

Stejně tak se tam střídá high a low přístup, podle toho, jakou roli v systému máš a co zrovna řešíš. Máš data a potřebuješ z nich získat nějakou podmnožinu? High, abstraktně si se systémem povídáš o tom, co bys chtěl. Máš high-level postup z přechozího příkladu, ale potřebuješ ho zrychlit? Low level šťourání v tom, jak přesně jsou data uložená, jak jsou mezi nima realizované vazby, co přesně systém ví o těch datech, co ty víš o datech a systém neví, jak mu vlastně vnutit, aby se choval podle těch informací, které ve skutečnosti nemá a ty jo, atd.

[Sosacek]

Kdyz tak mluvis o SQL, tak bych zminil, ze PL/SQL je pekna mrdka, novodoby COBOL a zaslouzi si prestat existovat.

[Pieta]

Kdyz tak mluvis o SQL, tak bych zminil, ze PL/SQL je pekna mrdka, novodoby COBOL a zaslouzi si prestat existovat.

Rozhodně mě nepřistihneš při tom, že bych se pl/sql nějak moc zastával. (: Ne že bych se nějak moc věnoval jeho historii, ale čistě z toho, jak vypadá, bych si tipnul, že cílem nebylo ani tak vyvinout jazyk, jako spíš mít něco, v čem se dá napsat for cyklus a deklarovat metoda. Integrace s SQL je zoufalá - každé přepnutí z jednoho do druhého a zpátky má nezanedbatelný overhead, a SQL má nulovou* schopnost zahrnout náročnost pl/sql věcí do přípravy spouštěcího plánu...

*) A to není nadsázka, doslova nulovou

[Sosacek]

Smutny je, ze cast tech duvodu proc pouzit pl/sql je, ze v Oracle je omezene sql - na spoustu uloh, na ktere staci jinde sql musis psat proceduru a tak. Typickym prikladem je merge a jeho zamykani(*) nebo ruzne pokusy pouzivat relacni db jako work/message queue(**).

Treba v "referencni rozumne implementaci sql standardu" tj. v postgresu muzu udelat "jestli neco existuje, tak to aktualizuj, pokud ne, tak to zaloz" jednim sql, aniz bych padal do nejakeho proceduralniho jazyka. Muzu udelat "updatni radky a vrat do aplikace co jsi updatoval". To jsou dva uplne jasny kusy, ktery se pouzivaji vsude mozne a neni moc pekne muset kvuli tomu lezt do pl/sql.

Pouzivat relacni databazi jako frontu neni dobry napad (semantika mvcc a semantika front jsou naprosto opacne veci) ale casto to tak dopada, protoze pouzivat relacni db a frontu znamena muset se hodne dobre zamyslet, jestli nepotrebuju distribuovane transakce a to saje.

(*): coz dava sysla, pac Oracli serializable neni serializable, ale to taky dava smysl, protoze nez vysel tenhle clanek tak vlastne slo delat serializable jenom pomoci dvoufazoveho zamykani, jak to dela SQL server, coz ma osklive vykonove dopady.

(**): for update skip locked -> fuj

[Vallun]

Dotaz - kamarádka shání někoho, kdo by věděl něco o tom, jak udělat mapovou aplikaci s několika vrstvami informací pro jejich veřejně prospěšnou společnost (zaměření na ochranu zvířat). Víte o tom někdo něco, prosím?