Příspěvky

1

Sítě / Re:Platforma pro domácí alarm/chytrou domácnost schopná odesílat SMS

« kdy: 09. 01. 2024, 12:54:59 »

Za mne:

- HW - Raspberry
   - připojíš k tomu co si zamaneš
   - všude spousta návodů a podpory
- SW - Home Assistant
    - integrace skoro všeho co si vzpomeneš
    - všude spousta návodů a podpory (např. parádní seriál na root.cz)
- připojení senzorů - ZigBee USB modul (podporovaný v HA)
    - velké množství hotových dostupných senzorů i efektorů (např. Ikea, Lidl, Philips, ...)
    - dostupné kity pro vytváření vlastních senzorů a efektorů
    - je to mesh síť
    - podpora v HA + Raspberry + USB Zigbee modul
    - všude spousta návodů a podpory

2

Sítě / Re:Jak protáhnout optiku trubkou do obýváku?

« kdy: 26. 01. 2022, 10:05:30 »

V tomhle ohledu pokud by tam muselo stejne byt koncove zarizeni (prevodnik navic), tak bych jej nechal u mericu a misto tel. kabelu bych s jeho pomoci natahnul klasicke UTP, ktere muze poslouzit i poe pro napajeni z obyvaku. Tohle je podle me nejjednodusi funkcni reseni.

... a já bych k té zprávě dodal jen to, že do SFP potrtu na Omnii můžete dát RJ45 SFP modul (https://www.alza.cz/ubiquiti-uf-rj45-1g-d5596804.htm) ... pokud máte málo portů ...

3

Sítě / Re:Česká firma implementující PacketFence

« kdy: 25. 10. 2021, 14:57:18 »

Děkuji, já se do toho nechci vrhat bez někoho "na telefonu", na to mám na správu příliš věcí ...

4

Sítě / Česká firma implementující PacketFence

« kdy: 24. 10. 2021, 13:21:54 »

Dobrý den,
je tu někdo kdo má zkušenosti s PacketFence?
Víte o nějaké české firmě která by ho uměla nasadit a následně podporovat?

Díky PK

5

Server / Re:Kam ukládáte Docker image on-prem?

« kdy: 12. 07. 2021, 07:07:24 »

Moje vlastní image registry?

https://hub.docker.com/_/registry

6

Vývoj / git --graph, různá repo, různé chování ...

« kdy: 03. 02. 2021, 10:45:39 »

Dobrý den,

mám otázku ke git --graph .

Oba jsou mnou založené, ze stejné workstation, pomocí CLI git. K oběma přistupuji ze stejného PC, k oběma se chovám stejně - "branchuji, comituji, pushuji, merguji ... ;-) " Pokud se ale podívám na na historii pomocí git log --all --graph --abbrev-commit tak vidím dva různé výstupy ...

branchuji = git checkout -b new_branch master
merguji = git checkout master ; git merge -m "popis" new_branch

A ať hledám jak hledám tak nemůžu najít proč se tak různě chovají ... (např. .git/config jsou equivalentní)

Tento očekávám:

Kód: [Vybrat]

$ git log --all --graph --abbrev-commit
*   553a5f1 (HEAD -> deploy, origin/deploy) faster testing without inventory file
|\ 
| * cdfa823 (origin/master, origin/HEAD, master) faster testing without inventory file
| * 291273a linted test file
* | ab05f0b ansible-lint test is too harsh
* |   c83ee1a Merge branch 'deploy'
|\ \ 
| |/ 
|/|   
| *   485ee21 Merge branch 'master' into 'deploy'
| |\ 
| * \   2860e91 Merge branch 'master' into 'deploy'
| |\ \ 
* | | | 7ad01a3 print OS release
* | | | afb186b Ansible localhost test playbook
* | | | da002ed sshpass needed
* | | | 987c22b ssh pass needed
* | | | cb821ab support for NETBOX
| |_|/ 
|/| |   
* | | 0a1c3f3 remove debug trace on deploy
| |/ 
|/|   
* | 6d63a59 install Ansible Galaxy drivers

Tento mne překvapil, protože v tomto repu dělám branche a merguji úplně stejně ...:

Kód: [Vybrat]

$ git log --all --graph --abbrev-commit
* 95b826a (HEAD -> master, origin/master, origin/HEAD) description for deploy stage
* 28a192f corect playbook filenames for CI/CD
* a5929b9 (origin/ansible_dir, ansible_dir) move to ansible dir
* 9691721 remove old testing files
* 66fca3e hostvars safe dafaults
* 397e1fa test network reachability
* a1bedac hopefully stable inventory
* 6b1ecac ignore tmp_inventory.yml
* 4046e71 typpo in filename
* 7b04784 linter configurations
* 77ffe65 linted by 'yamllint' and 'ansible-lint'
* cc4bcd0 are devices reachable?
* c118b33 add dummy playbooks
* b8dbd6a add dummy playbooky
* 6ff2efc force linted playbooks
* 147d777 (origin/cicd) remove debug output
* b8689ae remove too harsh ansible-lint


7

Server / Re:SAN - profesionální řešení okolo 50 tisíc, resp. do 100 bez disků

« kdy: 01. 02. 2021, 12:25:16 »

Jsou už s VMware, ale jen Essential, alespoň že pod supportem.

Takže Proxmox nebo OpenStack nepřichází v úvahu ... Obávám se, že skončíte u toho FreeNAS ...

8

Server / Re:SAN - profesionální řešení okolo 50 tisíc, resp. do 100 bez disků

« kdy: 01. 02. 2021, 12:23:21 »

Navíc se vSAN platí zvlášť a stojí to raketu, každý server má 2 CPU a virtuálů je hodně.
AD ROBO - tedy Remote Office Branch Office (Standard) je omezený jen na 25 virtuálů.

Pokud by nebylo 25 VM omezení, tak v rámci ROBO je vSAN v ceně ...

9

Server / Re:SAN - profesionální řešení okolo 50 tisíc, resp. do 100 bez disků

« kdy: 01. 02. 2021, 12:05:26 »

Jsou už ty servery a VMWare koupeny?

Tohle je jasná úloha pro vSAN a v případě ROBO licencí je to skoro za hubičku ...

10

Vývoj / Re:Jak posunout vývojáře k CI/CD

« kdy: 29. 01. 2021, 14:06:02 »

Ako som precital diskusiu tak ja som situaciu takto pochopil:

To nie su programatori. To su ludia ktorych napln prace je nieco ine a su schopny nejake percento casu dajme tomu 30% (alebo nedajboze dokonca vo volnom case) venovat programovaniu a napisat nejaku utilitu pre firmu. Ak je to takto tlacit ich do gitu ked to nechcu imho nema zmysel. Ak chcete git,ci/cd najdite si fulltime vyvojara.

Pokud programuje, pořád je to programátor, byť na part time. A furt je to zaměstnanec, takže má sklapnout krovky a dělat práci pořádně, pokud ho k tomu někdo vyzve.

Tak to pozor. To není pravda. Zaměstnanec má náplň práce uvedenou v pracovní smlouvě. Pokud tam nemá nic o programování tak to není programátor a firma to po něm ani nemůže chtít. To že si zaměstnanec práci ulehčí/zrychlí automatizací/programem/zlepšovákem  automaticky neznamená, že výsledná práce je majetkem firmy, opět pokud není uvedeno v pracovní smlouvě,  že to je to co má dělat. Může se ovšem s firmou domluvit a třeba jí to prodat.

Osobně jsem zažil odejítí technologa (chtěl zvednout mzdu), který měl makra v Excelu, které dokázali spočítat parametry najetí a pracovní režim jistého zařízení řádově za minuty. Najmuli cucáka a při odstávce se zjistilo, že najetí nebude schopen zvládnout v určeném čase. Zkoušeli to týden. Pak se pokorně přišourali za starým technologem, ten vzal notebook a na místě z dodaných parametrů provoz najel. K zařízení byly k dizpozici příručky, plány, tabulky, grafy i vzorce, ale za prvé cucák neměl zkušenost a za druhé v příručkách se ještě počítalo na logaritmickém pravítku. Skončilo to tak, že vedení podniku se dohodlo se starým technologem a ten excelovský list za vyšší šesti místnou částku koupilo.

Je to poněkud starší příběh, ale dávám ho k dobru na jednání se zákazníky (vedení firem), aby si uvědomili, že o klíčové zaměstnance je potřeba se starat.

Tak tohle bych podepsal ... (naši parttime (cca 70%) progamátoři to mají ve smlouvě ...)

Ona ta má snaha vůbec nesměřuje k "nahrazení" lidí. Kód je jedna věc, je do něj uloženo spousta vědomostí, ale zkušenost je nepřenosná.

Ať to zní jak korporátní blábol, lidi - přiznejme že jen někteří - jsou největší kapitál firmy.

11

Vývoj / Re:Jak posunout vývojáře k CI/CD

« kdy: 29. 01. 2021, 09:25:10 »

Kdyby tazatel nebyl slaboduchý blbec vymyslel by efektivnější řešení bez nutnosti zbytečně práce lidí okolo se stejnými výsledky. Smyslem IT bylo vždy ulehčit, ušetřit čas a nikoliv věnovat tomu více času. POKUD NA TO MUSÍ NĚKDO MYSLET A VĚNOVAT TOMU 1 a více sekund je to ŠPATNÉ(NEVHODNÉ) ŘEŠENÍ. Tak jsme to vždycky dělaly a měli úspěch.

Děkuji za chválu, moc potěšila. Doufám, že i Vám udělala hodně dobře.

Já to vidím takto:
Že sjednocení správy zdrojových kódů přinese nějakou práci i vývojářům je jasné. Prostě ten kód musí pushnout do repository (odhad 1-3 min. denně).
Výhodu pro ně samotné to moc mít nebude .... alespoň ze začátku. Pokud jim verzování kódu nepřipadá užitečné teď proč by mělo být v budoucnu jinak, že ...

Pro mne jako toho kdo ty aplikace nasazuje a následně spravuje to bude mít výhodu, že budu moci s aktuálními verzemi dělat testovací instalace a dopředu si testovat (pokud možno automaticky) jestli aplikace se změnou kódu náhodou nepotřebuje jiné nastavení prostředí ... protože když na tohle narazíte při ostré instalaci tak má jak programátor, tak já o práci postaráno, někdy i na několik hodin (vrátit starou instalaci, zjišťovat kde je problém v nové program/prostředí, další pokus-omyl ...). Určitě to neodhalí vše, ale i 30% bude super.
Následně bych chtěl testovat samotný kód jak co do syntaxe tak statickou analýzou a pomáhat/psát pro vývojáře testy, to pomůže nám oběma ...

Pro firmu to má tu výhodu, že znalosti uložené ve zdrojácích jsou pod kontrolou. A pokud se testování pozitivně projeví na spolehlivosti nebo rychlosti nasazení, tak to je jen další plus ...

12

Vývoj / Re:Jak posunout vývojáře k CI/CD

« kdy: 29. 01. 2021, 08:37:42 »

...

Nyní jdou dělat věci, co předtím kolegové dělat nemohli. Můžeme přesně dohledat každou individuální změnu, zavedl se ticketovací systém (v Gitlabu), každý má 100% přehled o tom, jaké bug-fixy po něm ostatní chcou.

Celá tahle epopej byla osvobozující.

Díky za trochu naděje ... ;-)

13

Vývoj / Re:Jak posunout vývojáře k CI/CD

« kdy: 28. 01. 2021, 15:26:22 »

Děkuj vám všem za názory a rady.

14

Vývoj / Re:Jak posunout vývojáře k CI/CD

« kdy: 27. 01. 2021, 18:07:22 »

Jinak mě nic moc nenapadá, zřejmě i proto, že můj pohled je zkreslený (verzování považuji za velmi užitečný základ). Ale pokud to nikdy neviděli a nepracují moc týmově (jeden vývojář obvykle spravuje sám určité aplikace), tak se výhody (z jejich pohledu) ztrácejí.

No toho jsem se bál ...

Je to pre DevOps klasika ... tady máš program, mě to na PC funguje, je to tvůj problém ...

15

Vývoj / Re:Jak posunout vývojáře k CI/CD

« kdy: 27. 01. 2021, 18:03:27 »

To mají zdrojáky umístěné na nějakém sdíleném disku, a tam to všichni editují? Nebo to editují přímo na produkčním serveru? O jaký jazyk se vůbec jedná?

Ne, ty zdrojáky jsou v zásadě ve dvou kopiích ... u vývojáře a v běhovém prostředí.
Vesměs se jedná o jednoúčelovky které buď z technologií tahají data, transformují je a ukládají do DB, nebo jen předžvýkají a předhazují jiným např. dodávaným aplikacím a/nebo jen dodatečné report pro obsluhu ...

Z části je to PHP a/nebo JS, něco Java, něco C# ... u těch posledních dvou je kopie možná jen jedna ...

Podle mne nám chybí nějaký kontext. Je zbytečné přemýšlet o zavádění CI/CD, když vývojáři nevidí přínos VCS nebo jeho zavedení považují za příliš nákladné. Je potřeba vidět, jaké problémy současné řešení způsobuje vývojářům a jaké dalším lidem okolo. Přičemž je dobré to ještě rozdělit na ty problémy, které si vývojáři uvědomují, a na ty, které nevnímají. A také jaké přínosy v současném řešení vidí.

Kontext ... spousta cca 35 malých "pomocných" aplikací, které když nepojedou, tak ztratíme část funkcí, něco půjde dělat ručně, něco ne. Zmizí celkem dost reportů ...

Další kontextová část je, že nikdo z nich není vývojář na 100%, část času (30%) věnujou údržbě dodaných aplikací ...

Ohledně CI/CD ... tady beru VCS jako základ od kterého se odpíchnout a ostatní věci nabalovat postupem ...