Archívum - Jan 2016
február 1
Making a Murderer: 7 Hilarious Things Wrong with Ken Kratz’s Website
Az elkövethető legrosszabb design és UX hibák gyűjteménye
■ IPv6 - tudnátok segíteni, hogy hogyan kezdjek neki?
Szerettem volna kipróbálni az IPv6-ot, de elakadtam vele.
Odáig eljutottam, hogy a routerem kap egy v6-os címet+64bites prefix-szel egy tartományt.
A router mögött lévő gépek már izgalmasabbak. Címet mindenki kap az adott tartományból, de Windowson nem tudom használni. O.K., ez lehet a wifi driverem hibája, lehet az enyém, de akár a windowsos tűzfal is bekavarhat. Mondjuk az elég fura, hogy reboot után csak fe80::-as címeket kapnak az interface-ek, egy admin joggal indított cmd.exe-ből kiadott ipconfig/renew/all után már megkapja a szabályos v6-os címet... de ez annyira nem izgat egyelőre.
Van linuxom önálló gépen is, meg a Windows-on futó virtualboxban is. Ezekről a ping6, traceroute6 gond nélkül megy a v6-on elérhető szerverek felé. A Debian alapú linuxokon az apt-get is a v6-os címen éri el a repokat, amiket lehet. Viszont a test-ipv6.com és az ipv6-test.com oldalak azt állítják, hogy nincs IPv6 a gépeken... vajon miért?
Aztán ott a router és a benne lévő tűzfal. Ez vajon mit véd? Netfiltert (iptables6) használ, de vagy félreértettem valamit, vagy minden gép a saját címével megy ki a netre, azt meg... tudja védeni a router tűzfala?
Ha jól tudom, v6 alatt nincs NAT, legalábbis nem a v4 alatt megszokott formában (tévedek?)
A v4+NAT használatakor egy netstat-nat paranccsal meg tudom nézni, a router mögött álló gépek hová csatlakoznak. IPv6 esetében van erre lehetőség?
Olvasgattam wikit, ubuntu, freebsd doksikat v6-ról, de vagy átsiklottam felette vagy ilyesmiről nincs szó bennük.
■ Odáig eljutottam, hogy a routerem kap egy v6-os címet+64bites prefix-szel egy tartományt.
A router mögött lévő gépek már izgalmasabbak. Címet mindenki kap az adott tartományból, de Windowson nem tudom használni. O.K., ez lehet a wifi driverem hibája, lehet az enyém, de akár a windowsos tűzfal is bekavarhat. Mondjuk az elég fura, hogy reboot után csak fe80::-as címeket kapnak az interface-ek, egy admin joggal indított cmd.exe-ből kiadott ipconfig/renew/all után már megkapja a szabályos v6-os címet... de ez annyira nem izgat egyelőre.
Van linuxom önálló gépen is, meg a Windows-on futó virtualboxban is. Ezekről a ping6, traceroute6 gond nélkül megy a v6-on elérhető szerverek felé. A Debian alapú linuxokon az apt-get is a v6-os címen éri el a repokat, amiket lehet. Viszont a test-ipv6.com és az ipv6-test.com oldalak azt állítják, hogy nincs IPv6 a gépeken... vajon miért?
Aztán ott a router és a benne lévő tűzfal. Ez vajon mit véd? Netfiltert (iptables6) használ, de vagy félreértettem valamit, vagy minden gép a saját címével megy ki a netre, azt meg... tudja védeni a router tűzfala?
Ha jól tudom, v6 alatt nincs NAT, legalábbis nem a v4 alatt megszokott formában (tévedek?)
A v4+NAT használatakor egy netstat-nat paranccsal meg tudom nézni, a router mögött álló gépek hová csatlakoznak. IPv6 esetében van erre lehetőség?
Olvasgattam wikit, ubuntu, freebsd doksikat v6-ról, de vagy átsiklottam felette vagy ilyesmiről nincs szó bennük.
január 30
Managing Programmers by Douglas Crockford at Silicon Valley Code Camp
Hogyan menedzseljünk hatékonyan egy fejlesztőcsapatot
■ Docker-el hogy megy a build & deploy?
Érdekelne, hogy mi a best practice, ha docker container-ben szeretném futtatni az alkalmazásom. Több kérdésem is van.
- Érdemes ugyanabba a container-be tenni az adatbázist szervert, mint az alkalmazást? Abból indulok ki, hogy a docker-nek az a lényege, hogyha elszáll egy container-rel egy alkalmazás, az nem zavarja a többit, és ugyanúgy futnak tovább. Ebből gondoltam, hogy nem jó, ha közös adatbázis szerver van, mert ha az elszáll, akkor magával rántja az összes alkalmazást. Arra gondoltam helyette, hogy minden alkalmazás kapjon dedikált szervert. Ebből meg már következett, hogy talán jó, ha minden alkalmazás kap egy container-t, aztán abba megy minden ilyen infrastruktúrális dolog is. Jól gondolom?
- Hogyan megy a tesztelés? Addig eljutottam, hogy a sebesség érdekében a fejlesztői gépen érdemes a unit meg integrációs tesztek egy részét lefuttatni, mielőtt az éles környezetre hasonlító container-ben tesztelném. Arra gondoltam, hogy minden commit előtt érdemes egy ilyen container-ben történő, valamivel lassabb teszt. Nem teljesen világos, hogy hogyan rakjam össze az image-t, ami az ilyen teszteket végzi majd.
- Az sem teljesen világos, hogy a tesztelés után hogyan kerül majd az éles környezetre a jól működő build-elt kód anélkül, hogy az éles környezetben lévő adatok elvesznének. Tippre le kell állítani az éles rendszer előző verzióját, megtartani a volume-t, ami az adatokat tárolja, backup-olni a volume-t, aztán elindítani az új verzió image-ét, és csekkolni, hogy minden okés e. Ez elég időigényes. Nekem mondjuk nem gond saját célra készülő alkalmazásoknál, de azért érdekel, hogy olyan környezetben mindez hogy zajlik, amiben nem lehet hosszabb megállás.
Jó lenne néhány támpont ezzel kapcsolatban. Egyelőre nagyon kezdő vagyok docker-ezésben. Ezek az elméleti kérdések érdekelnek, a gyakorlatban meg tudom valósítani a dokumentáció végignyálazásával.
■ - Érdemes ugyanabba a container-be tenni az adatbázist szervert, mint az alkalmazást? Abból indulok ki, hogy a docker-nek az a lényege, hogyha elszáll egy container-rel egy alkalmazás, az nem zavarja a többit, és ugyanúgy futnak tovább. Ebből gondoltam, hogy nem jó, ha közös adatbázis szerver van, mert ha az elszáll, akkor magával rántja az összes alkalmazást. Arra gondoltam helyette, hogy minden alkalmazás kapjon dedikált szervert. Ebből meg már következett, hogy talán jó, ha minden alkalmazás kap egy container-t, aztán abba megy minden ilyen infrastruktúrális dolog is. Jól gondolom?
- Hogyan megy a tesztelés? Addig eljutottam, hogy a sebesség érdekében a fejlesztői gépen érdemes a unit meg integrációs tesztek egy részét lefuttatni, mielőtt az éles környezetre hasonlító container-ben tesztelném. Arra gondoltam, hogy minden commit előtt érdemes egy ilyen container-ben történő, valamivel lassabb teszt. Nem teljesen világos, hogy hogyan rakjam össze az image-t, ami az ilyen teszteket végzi majd.
- Az sem teljesen világos, hogy a tesztelés után hogyan kerül majd az éles környezetre a jól működő build-elt kód anélkül, hogy az éles környezetben lévő adatok elvesznének. Tippre le kell állítani az éles rendszer előző verzióját, megtartani a volume-t, ami az adatokat tárolja, backup-olni a volume-t, aztán elindítani az új verzió image-ét, és csekkolni, hogy minden okés e. Ez elég időigényes. Nekem mondjuk nem gond saját célra készülő alkalmazásoknál, de azért érdekel, hogy olyan környezetben mindez hogy zajlik, amiben nem lehet hosszabb megállás.
Jó lenne néhány támpont ezzel kapcsolatban. Egyelőre nagyon kezdő vagyok docker-ezésben. Ezek az elméleti kérdések érdekelnek, a gyakorlatban meg tudom valósítani a dokumentáció végignyálazásával.
január 29
PHP változó elfelejti tartalmát
Üdvözletem!
Van egy kódom:Tegyük fel, hogy az összes tagfüggvény megvan, továbbá egy belső változó, ais.
Amikor végrehajtom ezeket, a $this->query tagváltozóba írják a maguk dolgait (pl. "column" => ["sor", "másodsor"]), így végül aznevű tagfüggvény az alapján végre tudja hajtani a lekérdezést.
A kérdésem az lenne a fenti koncepcióval kapcsolatban (amely a hiba keletkezése előtt (kb. 6x) jól működik) az lenne, hogy az említett $this->query tagváltozó az egyik metódus meghívásakor (Value()) hogyan lehet üres, mikor már fel lett töltve?
Van egy kódom:
$this->database
->Add()
->Col("which", "ident", "date", "time", "client")
->Value($which, $id, Sanitizer("toSTDdate")->Sanitize(getTime()), Sanitizer("toSTDtime")->Sanitize(getTime()), getClientID())
->Table("form");
$res = $this->database->Execute();
$this->query
Amikor végrehajtom ezeket, a $this->query tagváltozóba írják a maguk dolgait (pl. "column" => ["sor", "másodsor"]), így végül az
Execute()
A kérdésem az lenne a fenti koncepcióval kapcsolatban (amely a hiba keletkezése előtt (kb. 6x) jól működik) az lenne, hogy az említett $this->query tagváltozó az egyik metódus meghívásakor (Value()) hogyan lehet üres, mikor már fel lett töltve?
V8 Release 4.9
A Google Chrome 49-es verziója 91%-os ES2015 támogatással érkezik
■ január 29
NixOS – The Purely Functional Linux Distribution
Deklaratív, tranzakcionális csomagkezelésre és konfigurációra épülő Linux disztribúció
■ Google Will Soon Shame All Websites That Are Unencrypted
A nem biztonságos weboldalak vizuális megjelenítése hamarosan megváltozik a Google Chrome-ban
■ január 28
Knightmare: A DevOps Cautionary Tale
Hogyan vitte az automatizálás hiánya negyvenöt perc alatt csődbe az Egyesült Államok legnagyobb tőzsdei kereskedőjét
■ 
