ugrás a tartalomhoz

Archívum

szeptember 22, 2017

Mit értett ez alatt Alan Kay?

inf3rno · Szep. 22. (P), 14.15
Smalltalk is not only its syntax or the class library, it is not even about classes. I’m sorry that I long ago coined the term “objects” for this topic because it gets many people to focus on the lesser idea. The big idea is “messaging” … The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Think of the internet – to live, it (a) has to allow many different kinds of ideas and realizations that are beyond any single standard and (b) to allow varying degrees of safe interoperability between these ideas. If you focus on just messaging – and realize that a good metasystem can late bind the various 2nd level architectures used in objects – then much of the language-, UI-, and OS based discussions on this thread are really quite moot.


Egész pontosan a The big idea is “messaging” rész, az ami nagyon homályos. Próbáltam utánajárni, sokan kérdezték Alan Kay-t erről, de mindig ködösített, és sosem mutatott egyetlen példát sem, hogy szerinte hogyan kellene egy oo nyelvet helyesen használni. Van valakinek bármi ötlete?
 

szeptember 21

systemd

inf3rno · Szep. 20. (Sze), 23.55
Olvasgattam az utóbbi napokban a disztrók legtöbbje által manapság használt init rendszer, a systemd körüli vitákról. Kíváncsi vagyok a véleményetekre, hogy szerintetek egy szerveren vagy desktop környezetben mennyire ajánlott a használata, esetleg rejt e valamilyen biztonsági kockázatot.
 

szeptember 17

Netacademia videok?

mahoo · Szep. 17. (V), 09.44
Van valakinek velemenye a Netacademia-s videok szakmai szinvonalarol?
Basic csomaggal szemezem, aminek ara, ha szinvonalas videokat kap az ember akkor csekely, ellenkezo esetben meg borsos.

Minden velemenyt szivesen fogadok!
 

szeptember 15

Tiszta kód

Hidvégi Gábor · Szep. 15. (P), 12.25
janoszen egy másik fórumszálban linkelte egy OOP példakódját egy kezdő kérdésére válaszolva, ehhez lennének kérdéseim és hozzáfűznivalóm, ezért kiemeltem egy külön témába.

A programból le lehet vonni azt a következtetést, hogy OOP-t ott lehet érdemes használni, ahol egy bizonyos funkciót legalább kétszer megvalósítunk, mert ad egy szabványos interface-t, amivel tudunk kommunikálni.

Viszont itt jön a kérdés, hogy hol találkozunk ilyen bonyolultságú projekttel? Hol van szükség arra, hogy ugyanolyan típusú adatokat (mondjuk blogbejegyzés) két vagy több különböző adatforrásból halásszunk össze?

Hol van szükség arra, hogy akár többféle router is lehet a rendszerben? Ha viszont csak egyet használ a projekt (márpedig a fenti blogmotorban csak egy van), akkor miért van általánosan megvalósítva? Hisz így egyrészt van egy minimális overhead, másrészt plusz munkával jár. De ki tudja, hogy mit hoz a jövő? Mi lesz, ha a mostani router interface nem megfelelő? Akkor lehet refaktorálni, azaz fölösleges melót tett bele az, aki a jelenlegit írta.

Felmerülhet az is, hogy miért keverednek a php és a sablon fájlok? Mi közük van egymáshoz? De ez apróság.

Kérdés, hogy tényleg olyan kivételes helyzet, ha olyan konfigurációs beállítást kérdezünk le, ami nem létezik? Ettől a program futásának meg kell állnia?

Kérdés, hogy miért van több kivétel definiálva, amikor nincsenek kifejtve, azaz a kódjuk megegyezik?

Kérdés, hogy a BlogPostInteractor miért példányosítja a kétféle lekérdezési módot? Mi van, ha egy adott oldalon csak az utolsó n darab bejegyzésre van szükségünk, de az egyes posztokra nem? Ez is egy apró overhead.

Kérdés, hogy ha a kivételek típusa (Exception) megjelenik a fájlnévben, akkor az interface-eké miért nem?

Kérdés, hogy kezdőknek ez alapján kéne elkezdenie programozni?

---

Értem én, hogy példakód, de azért ez egy kezdő számára ijesztő lehet.

szeptember 13

INNER JOIN probléma

Termes · Szep. 13. (Sze), 11.13
Sziasztok!

Új problémába ütköztem és ennek megoldásában kérnék segítséget.

Adott a lekérdezés, melyet össze kellene vetnem az egy évvel ezelőtti adatokkal és csak a közös elemeket listázni.

SELECT * FROM reszletek 
INNER JOIN tabla 
ON reszletek.id=tabla.id 
WHERE tabla.szolgalat = '2' 
AND reszletek.kesz = '1' 
AND reszletek.adatbazis = '6' 
AND reszletek.frissites_datum 
BETWEEN '2016-01-01' AND '2016-08-31' 
GROUP BY tabla.id

SELECT * FROM reszletek 
INNER JOIN tabla 
ON reszletek.id=tabla.id 
WHERE tabla.szolgalat = '2' 
AND reszletek.kesz = '1' 
AND reszletek.adatbazis = '6' 
AND reszletek.frissites_datum 
BETWEEN '2017-01-01' AND '2017-08-31' 
GROUP BY tabla.id
Ezt hogy lehet egy körben lekérdezni? Köszönöm.
 

szeptember 11

Session biztonsági ellenőrzés

peterkerdez · Szep. 11. (H), 19.32
Sziasztok! Adott egy weboldal, amin eddig úgy ment a felhasználók session adatainak ellenőrzése, hogy a felhasználó nevét, aktivitását stb. ellenőriztem, azonban minden különálló oldalon ugyanolyan módon, az oldal elejére beillesztve a kódot. Mivel szeretném áttekinthetőbbé tenni az oldalak kódját, ezért arra gondoltam, hogy kiraknám egy külső fájlba a webrooton kívül, ahonnan a phpval require_once beolvasnám és funkcióként minden oldal elejére helyezném. Két dolog jutott eszembe:

Mi van, ha nem létezik a bekért include? Ekkor automatikusan leáll a php fordítása fatális hibával már a kód elején, tovább nem lehet használni.

Mi van, ha nem létezik a szükséges function? Ebben az esetben szintén fatális hibával le fog állni a php fordító, tovább az oldal nem használható.

A require_once esetében kézzel (saját kódon belül, nem felhasználói input) felvitt útvonallal adom meg a biztonsági ellenőrzést végző függvény fájlját.

Okoz-e biztonsági problémát ez, mire kell figyelnem ezeken kívül?

illetve

Kevésbé lesz-e biztonságos a weboldal, ha ilyen módon történik a felhasználók jogosultság vizsgálata ahelyett, hogy minden oldal elején ugyanaz a kód szerepelne? A function sessiont vizsgál, amit eddig minden oldal eleje tett meg.

Köszönöm a segítséget!
 

szeptember 5

Laravel 5 routing

csabessz47 · Szep. 5. (K), 20.50
Sziasztok,

Laravel 5-ben nem jöttem még rá egy routinggal kapcsolatos probléma megoldására, minden segítség jól jönne.

A route fájlok kisebb fájlokra van bontva, minden "csomaghoz" tartozik egy.
Egy /budapest url estén
Route::get('{url}', .....)
szeretnék olyat, hogy
- először megnézi pl a videók route fájljában, hogy tud-e visszaadni valamit (mondjuk ahol a videó nevében benne van a "budapest")
- ha nincs semmi, akkor megy tovább a képek route fájljába, hogy van-e budapest nevű kép,
- ha nincs, akkor nézi a települések "csomaghoz" tartozó route fájlban, hogy van-e budapest nevű település.

Az url szerkezeten nem tudok változtatni, tehát nem lehet (/kepek/budapest, /videok/budapest).

Ha esetleg egy nagy route fájl lenne, ez pedig a legvégén, akkor is kéne egy nagy callbackbe gányolás...
Route::get('{url}', function($url, ImageRepository $imageRepository, VideoRepository $videoRepository, SettlementRepository $settlementRepository) {
    // van kép?
    $imageRepository->findByUrl($url);
    
    // ha nincs kép
    $videoRepository->findByUrl($url);
    
    // ha nincs videó
    $settlementRepository->findByUrl($url);
});
Route fájlokba belegányolni amúgy sem szeretek ilyet, több controllert hívogatni meg fura lenne :)

Vagy esetleg a route-ba adott callback-ben egy exceptiont dobni (vagy return null :), ami után a route listából jönne a következő, így maradhatna szétbontogatva...

Került már valaki ilyen helyzetbe?
Tudtok erre egy -lehetőleg- szép megoldást?

Köszi előre is
 

szeptember 4

Mekkora méreteknél érdemes több docker container-be darabolni az alkalmazást?

inf3rno · Szep. 4. (H), 00.39
Mekkora méreteknél érdemes több docker container-be darabolni az alkalmazást?
 

augusztus 23

hangosítás

aranycserepes · Aug. 23. (Sze), 10.05
Tisztelt Cím! A végzettséghez nem kötött vállalkozási tevékenységeknél, de a végzettséghez kötöttnél sem találtam a HANGOSÍTÁS-t. A vállalkozásba szerepel a hangfelvétel készítés. Kérdésem, számlázható-e a hangosítás, vagy milyen tevékenységet kell a vállalkozásba beépíteni. Kösszönöm
 

augusztus 22

Bocsánat kérés, Tatai László

Tatai · Aug. 22. (K), 09.07
Tisztelt Weblabor közösség.

Bocsánatot szeretnék kérni, mert régebben azt írtam a PHP listára, hogy könnyű programozni, és nehéz fizikai munkát végezni.

Tisztelettel : Tatai László