Klejojot par Diena.lv nejauši atradu Gunta Lauska blogu, kurā vienkāršiem vārdiem tiek izskaidrota personas datu apstrādes nianses.
Ja kādam ir robs šajā sfērā iesaku izlasīt- daudz labāk izskaidrots, kā likumā par personas datu apstrādi.
Klejojot pa netu atradu vienkārši saprotamus, bet manuprāt iedarbīgus baušļus- kā kļūt par vadītāju.
Protams zvaigšņu stāvoklis un IQ līmenis vienmēr būs svarīgs, bet neievērojot šos likumus ar tiem var būt par maz 
1. Līderis ne vienmēr nozīmē vadītājs.
Kļūt par līderi Talak »
Zinot cik atšķirīgi autentifikācijas un autorizācijas mehānismi tiek lietoti internetbankās izvēlējos tos papētīt un salīdzināt.
Ja ir papildus informācija vai info par citām bankām, droši padodiet ziņu būtu interesanti savāk informāciju par visām LV bankām un ne tikai.
Salīdzinājums ir sanācis ne pārāk acīm viegli uztverams, bet ja izdomāšu kā to attēlot labāk- izmainīšu.
Salīdzinājumu veicu darbībām ar koda kartēm un, sadalītiem soļiem izdalīju 1. soli un 2. soli
| Banka | Autorizācija | Darījumu apstiprināšana | Komentāri |
| Krājbanka
https://online.lkb.lv |
1. Solis Lietotājvārds, parole,2. Solis kodu kartes numurs(nemainīgs) | 1. Solis Kodu kartes numurs un nākošais pēc kārtas kods no kodu kartes. | Lai pieslēgtos kontam un apskatītu visu informāciju nav nepieciešams kods no koda kartes, tāpēc iegūstot pieejas informāciju varēs tai piekļūt nemitīgi.Katrs kodu kartes kods ir izmantojams tikai vienreiz- kad visi kodi ir izlietoti ir jādodas uz banku apmainīt kodu karti.
Lietotāja atbloķēšanai (pēc neveiksmīgām pieslēgšanas reizēm) ir jādodas uz banku. Izmantojot kadakarti vienā reizē var pārskaitīt naudas summu līdz 1000ls. |
| Norvikbanka
https://www.e-norvik.lv/ |
1. Solis Lietotājvārds, parole,2. Solis noteikts kods no kodu kartes | 1. Solis. noteikts kods no kodu kartes un lietotāja parole | Papildus modrībai- izvēles bilde, kuru man liekas neviens neizmanto. |
| DnB Nord
https://www.inord.lv/ |
1. Solis Lietotājvārds (ievadot neeksistējošu atgriežas 1. Solī)2. Solis Ieejas parole, noteikts kods no kodukartes | Nav info | Šādi var uzminēt kādu lietotājvārdu
Neierasti- ir jāatceras 2 paroles(apstiprināšanas un ieejas). Prasība parolēm- vismaz 2 cipari |
| Hanzabanka
https://hanzanet.lv |
1. Solis lietotājvārds, parole
(ievadot nepareizu lietotājvārdu un/vai paroli nepāriet uz otro soli) 2. Solis noteikts kods no kodu kartes |
1. Solis. Pirmie 3 cipari no kodu kartes noteikta koda | Lietotāja atbloķēšanu var veikt pa telefonu. Operators protams uzdod visādus interesantu jautājumus, bet personīgi zinu gadījumu, kad otrs cilvēks atbloķēja vai pat nomainīja ieejas paroli (toreiz tas bija ar labu nodomu, jo pats īpašnieks bija ārzemēs un netīšām nobloķēja sev pieeju- krājbankas gadījumā varētu “žāvēt airus” ) |
| SEB
https://ibanka.seb.lv |
1. Solis Klienta kods un parole (ievadot nepareizu lietotājvārdu un/vai paroli nepāriet uz otro soli)
2. solis noteikts kods no kodukartes |
Darījumu apstiprināšana | Papildus |
| Banka | Autorizācija | Darījumu apstiprināšana | Papildus |
Kopējā konstatētās problēmas ir, ka ja kāds ļoti sagribēs ieriebt visiem konkrētas bakas klientiem (tos nešķirojot), tad pārsvarā vienkārši vadot pēc kārtas katram lietotājam nepareizas paroles lietotājs tiks bloķēts un pieeja tiks liegta.. vienkārši bet iedarbīgi..
Iedomājieties LV banku X, kur vienu dienu neviens lietotājs nevar pieslēgties .
Change log:
Pievienots papildināums par krājbankas kodakartes ierobežojumu pārskaitījumam līdz 1000ls
Informācija par SEB (Unibanku)
Pāršķirstot vecus pierakstus atradu interesantu materiālu, kurā tika veikta komunikāciju iedalījums pēc to tipa: formāla, neformāla un rakstiska vai mutiska.
Pati par sevi šī tabula neko neizsaka, bet var kalpot kā labs uzskates līdzeklis. Iespējams kādam noderēs.
| Formālā | Neformālā | |
| Mutiski | Sapulce
Prezentācija |
Pīpētava
Kafijas pauze Pusdienas 1:1 (viens pret viens) |
| Rakstiski | Vēstules
Iesniegums Rīkojums |
e-pasts
Skype Čats |
No uzskaitītām efektīvākās skaitās:
Sapulces un neformālās 1:1 pārrunas
Visneefektīvākā skaitās e-pasts sarakste
Mūžīgais jautājums-
Kāpēc pasūtījumos bieži tiek noteikts:
soda nauda par termiņu kavējumu 0,1% par katru dienu, bet ne vairāk kā 10% no kopējā projekta summas?
Ar šādiem noteikumiem izstrādātājs var rēķināties ar 10% zaudējumu (sākumā palielina projektu summu par 10% un neko nezaudē ) un vispār neiespringst nedz uz kvalitāti, nedz termiņiem.
Un pēc tam amatpersonas cēli paziņo, ka mēs neko nevaram darīt (nevaram iespaidot vai ietekmēt izstrādātāju), jo redz iespējamā soda procentu summa jau ir izsmelta! Pamāj ar galvu un apsola nākotnē kļūdu novērst, bet nākošo līgumu noslēdz tieši tādu pašu? Kad tas beigsies?!
Ps. Ko es ar to gribēju pateikt? Nepieļaujiet tādas kļūdas..
Nesen bija tas gods izpildīt testu, pēc kura vienā uzņēmumā tiek vērtētas IT administratoru zināšanas.
Man šis tests bija interesants divu iemeslu dēļ:
Ja kādam gribas sevi pārbaudīt pēc “subjektīva zināšanu testa”, tad lūdzu. Protams, katram būs savs vērtējums vai ar šādu testu ir iespējams pārliecināties par admina spējām, bet tas tā… Talak »
Manas piezīmes par tēmu “zivs pūst no galvas”.
Daudziem ir zināma drūmā statika par to cik procentuāli daudz projektu izgāžas, neizdodas vai vienkārši nesasniedz savu sākotnējo mērķi.
Savā pieredzē arī esmu saskāries ar neveiksmīgiem projektiem, kurus vienoja divas būtiskas lietas.
Ps. Šeit nepieskaršos projektu vadīšanas procesam , jo tas ir atkarīgs no konkrētā projekta tipa, lieluma, utt.
Bet ir viena kopēja lieta- Projekta mērķis. Talak »
Vienu dienu izveidojās diskusija par indikatoriem, kas norādītu uz iespējamo krāpniecību uzņēmumā.
Kā viens no interesantākajiem man šķita ilglaicīgi neizņemts atvaļinājums, jo pats parasti turu rezervē vairākas atvaļinājuma dienas- ja nu pēkšņi ir nepieciešams kaut kur aizbraukt un tāpēc nesaskatīju tur neko nosodāmu. Talak »
Vienā sanāksē tika diskutēts, ko ir vērts pārbaudīt IT projekta ietvaros?
No visa iznāca divas galvenās atziņas:
Papildus tam projektu konsultēšanas laikā var palīdzēt izstrādāt dažādus kritērijus, pēc kuriem vadīties projekta laikā, tādā veidāatvieglot projektu vadītājam pieņemt lēmumu. Piemēram, kritēriji, kuriem jāizpildās, lai sistēmu varētu ieviest produkcijā(tai jābūt notestētai, veiktie stres testiem, drošības testiem, saņemta dokumentācija, utt) vai arī saņemtās lietotāju dokumentācijas kvalitātes un atbilstības analīze(to var salīdzināt pret LV standartu- LVS 66:1996), utt
Cits jautājums, vai šī analīze pēc tam tiek ņemta vērā..
Lasot projektu vadības standartu PRINCE2 uzgāju bildi, kurā ir nodalītas dzīves cikla sadaļas, kuras ir definētas kā produkta un kuras kā projekta daļas.
Nekā mega jauna jau nav, bet lasot atcerējos vecu strīdu ar bijušo kolēģi, par jautājumu vai sistēmas lietošana un uzlabošana ietilpst projektā vai arī izstrādes projekts beidzas ar lietošanas uzsākšanu.
IAI pagājušajā ikmēneša sapulcē tika diskutēts par IT auditiem un tipiskākajām problēmām IT projektos. Tādēļ, lai piefiksētu sev svarīgāko veicu apkopojumu, varbūt kādām noder. Prezentāciju vadīja Ēriks Dobelis.
Sākumā skaitļi- ap 84% IT projektu neiekļautās projekta sākumā nospraustajos termiņos un 56% neiekļaujas budžetā. Talak »
Iepriekšējais raksts: http://dll.lv/it-projektu-problemas-1/
2. Ieviešanas(izstrādes) problēmas
Galvenā problēma ir projekta plānošana, vadīšana un prasību definēšana.
Joprojām projekti tiek pasūtīti prasībās norādot vispārējas lietas, kuru realizācijas redzējums ļoti atšķiras starp pasūtītāju un izstrādātāju.
Biežāk izstrādē lietotās ir Agile un ūdenskrituma metodes.
Lielākā kļūda izstrādājot ir mēģināt apvienot abas izstrādes metodes un izgudrot kaut ko pa vidam, jo abās metodēs ir iestrādātas pilnīgi cita ideoloģija, kā rezultātā sistēma tiek izstrādāta pēc ūdenskrituma modeļa, bet ar nenodefinētu specifikāciju. Talak »
Meklējot nepieciešamās IT kompetences uzdūros interesantai lasāmvielai- ieteikumi administratoriem:)
Adminiem- Must know, jo ir daudzi, kuri par šīm dzīves īstenībām ir piemirsuši, līdz tām neaizdomājais vai vienkārši ignorē:
1. Nekad nedari to, ko nevarēsi pēc tam atjaunot iepriekšējā stāvoklī.
2. Vienmēr pārbaudi rezerves kopijas, nepaļauties tikai uz to esamību, bet pārliecināties, ka tiešām varēsi arī atjaunot.
3. Vienmēr pieraksti ko tu darīji, pat tad, kad uzskati, ka nekad to neaizmirsīsi.
4. Ja kaut ko dari vairāk kā vienu reizi, uzraksti skriptu, kas to darīs automātiski.
5. Iepazīsties ar lietotājiem pirms ir notikusi kāda problēma, jo kad tā notiks, viņi tevi jau pazīs un attieksies jau ar lielāku sapratni.
6. Atcerieks, ka nodrošini servisu lietotājiem, nevis esi sistēmas īpašnieks. Tu ar to darbojies, lai palīdzētu citiem.
7. Pārbaudi rezerves kopijas.
8. Nekad nepārtrauc mācīties, vienēr ir kaut kas jauuns, kas padarītu tavu sistēmu stabilāku, drošāku un tavu darbu vieglāku.
9. Atkal pārbaudi rezerves kopijas.
Sen sen atpakaļ viens draugs teica, sū… ar visu, ka tikai ir uztaisīts un pieejams backup Principā zelta vārdi…
Klejojot par zdnet.com uzdūros interesantam manteriālam, kur cilvēks ar lielu IT pieredzi dalās viņuprāt IT vadītājam Must have īpašībām un spējām(principā nekā jauna, bet atkārtošana zināšanu māte). Katrs var kritiskāk novērtēt vai tās viņam piemīt:
1. Spēja precīzi novērtēt uzņēmumam nepieciešamās vajadzības.
2. Spējai noteikt nākotnes vīziju vai mērķi ko gribat sasniegt
3. Spējai sastādīt plānu, lai sasniegtu savu mērķi
4. Spējai izveidot komandu
5. Spējai fokusēt iespējamos resursu
6. Spēja ieviest labu “klientu servisu”(nodrošinot, ka klientu problēmas tiek vērtētas visaugstāk)
7. Spēja vadīt proektus
8. Spēja ieviest izmaiņu vadības procesu
9. Spēja vadīt un motivēt
10. Spējai labi komunicēt
11. Spēja izsekot un mērīt veiktspēju
Visu šo laiku esmu jebkādu risku uztvēris tikai ar domu par iespējamajiem potencālajiem zaudējumiem, kuri var iestāties.
Tomēr izrādās, ka šim jautājumam var pieiet vairāk filozofisku un tad šī iespējamā riska iespaids vairs neliekās tik biedējošs.
Triviāls piemērs, kas atspoguļo šo ideju- situācija, ejot uz veikalu pastāv iespēja, ka izvēlētā priekšmeta tur nebūs. Talak »