- Motorola Edge 40 - jó bőr
- Bemutatkozott a Fairphone 6
- Samsung Galaxy Watch7 - kötelező kör
- Megjelent a Poco F7, eurós ára is van már
- Motorola Razr 60 Ultra - ez a kagyló könnyen megfő
- Honor Magic V2 - origami
- iPhone topik
- Xiaomi 14 - párátlanul jó lehetne
- Hammer 6 LTE - ne butáskodj!
- Eltűnhet a Dinamikus Sziget
-
Mobilarena
Új hozzászólás Aktív témák
-
nyunyu
félisten
A 85hz-es monitorok csak az ezredfordulón jöttek.
Tudom, elég unikornis vagyok, de '95 őszén vettem 170k-ért az iiyama MF-8617T-t, ami 1024x768 100Hz-t tudott, feltéve ha az akkori S3 videókártyám drivere tudott volna olyat.
('96-ban vett Matrox Mystique már jól kezelte.)'98-99 körül váltak bárki által megfizethetővé (<100k) az 1024x768@85Hz-t tudó 15"-ösök, egyszerűbb 17"-esek.
-
nyunyu
félisten
Ami még eszembejutott az, hogy a Pascal a kilencvenes évek végén kezdett eltűnni a programozás oktatásból.
Nekünk 98-ban még volt Pascal a BME infón, aztán eggyel alattunk évfolyamon kidobták a tantervből, hogy legyen helye az akkoriban egyre felkapottabb, terjedőfélben lévő Javának.Így aki még a kilencvenes években kezdett programozni, azoknak a Pascal után a Delphi egy logikus továbblépés volt ahhoz, hogy Win alkalmazásokat fejlesszenek.
De ennek az XP+.NET megjelenése tette be végképp a kaput, mivel a Borland ott nagyon bealudt és lemaradt, mint a borravaló.2000 után meg már mindenhol a Java folyt a csapból is, és az újabb programozó generációk már eleve abban tanultak fejleszteni.
-
-
-
nyunyu
félisten
Héten ment melóhelyen a fejvakarás, mert elkészült a banki mobilappunk, viszont az Apple csak úgy engedi ki az alkalmazásokat az appstoreba, ha minimum 5.7"-os kijelzős iPhoneokon készült screenshotokat mellékelsz mellé.
Mondani se kell, hogy az az appot hónapok óta nyomogató belsős bétatesztereknek régi iPhoneja vagy SE vagy minijük van, mert szegény az eklézsia, és feleslegesen nem cserélik évente az aktuális Pro Max-ra...
-
nyunyu
félisten
válasz
Diocles
#20329
üzenetére
Informatikai érettségiben mindkettőre van feladat.
(Nekünk 25 éve még az akkor bevezetett ECDL vizsgát erőltette a tanár gimiben, utáltam is érte, hogy negyedikben számtech tagozaton a rég beígért C helyett Word/Excel/PowerPoint ment
Úgyhogy se nem érettségiztem számtechből, se nem mentem ECDL vizsgára.) -
nyunyu
félisten
válasz
Vision
#20315
üzenetére
Amúgy én dolgozom együtt olyan fejlesztővel (BME-VIK), aki nem ismeri a HTML nyelvet. De tényleg, nulla. Nem is értem, mert amúgy középiskolás anyag.
BME VIK-re jártam, ne is kérdezd hány évig.Eredetileg távközlés, aztán sokadik nekifutásra C# fókuszú szakirányon voltam.
Tanítottak mindenfélét (Pascal, C, C++, Java? aztán C#, Java, webes valamik), végül DB, DWH oldalon kötöttem ki.
Arra emlékszem, hogy egyik évben még a .Net 2.0 webes frameworkjeit nézegettük szakirány laborokon, következőben a .Net 3.0-át (Razor?), szóval valamikor tizenéve nézegettem a HTML, CSS, JavaScript akármiket is, de azokhoz nagyon nem értek (ahogy a Java meg C#-hoz sem.)Ellenben nemrég melóhelyen hozzámvágtak egy 700 soros SQL queryt, amit az egyik vezető Java fejlesztőnk csinált 5+ éve, elvileg 15 táblából szedi össze az ilyen-olyan webshopok hiteligényléseinek az állapotát.
Csak túl sokáig fut, néha megfekszik tőle a DB szerver, aztán attól az egész alkalmazás.
Még nem sikerült átlátnom a teljes logikáját, de némelyik alquerytől agyrákot kaptam, annyira rossz a futási terve: számlaszámonként lekéri a dokumentumok állapotát, rendezi beérkezési dátumra, kiválasztja a legnagyobbat, majd veszi a következő számlaszámot, és arra megint rájoinol leválogat, rendez, szűr...
Ezeket kicseréltem olyanra, hogy először rendezem a táblát számlaszámra és beérkezési dátumra, abból válogatom le a számlaszámonkénti utolsó sorokat, így mindjárt nem többtízezer számlaszámra külön-külön fut a query, hanem egy menetben az egész.
Mindjárt lefeleződött a futási idő, és a szerver sem pusztul bele.
Elvileg az SQL is középiskolás anyag, de jól csinálni az megint más skillszetet, gondolkozásmódot igényel, mint mondjuk a Java programozás.
Nyilván ez a frontend cuccokra is igaz, nehéz az almát a körtével összehasonlítani. -
nyunyu
félisten
válasz
pmonitor
#20189
üzenetére
Nem teljesen értem, hogy miért akarnál egy magas szintű nyelvről szóló könyvtől gépi kód oktatást várni.
C# az gyakorlatilag egy modernizált C++, amit a Java konkurensének szántak.
Könnyen, gyorsan, biztonságosan fejlesszünk benne alkalmazásokat a lényege, nem az, hogy teljesítmény legyen, mint az alacsony szintű nyelveknél (ASM, valamelyest a C) -
nyunyu
félisten
válasz
Zola007
#20178
üzenetére
Miért akarnád a Windows beállításokat piszkálni?
Egyszerűbb a notepadban mentés máskéntet nyomni, aztán alul Kódolás legördülőben kiválasztani az ANSIt.
Akkor egy bájton menti a magyar ékezetes karaktereket, nem kettőn, mint az UTF8-nál, így minden nem UTF8-at használó rendszerben ugyanúgy fog működni, nem fog szétesni a string.De nem szeretem, ha figyelmetlen kollégák szkriptjei által elrontott DB kommenteket, meg ügyfélszolgálatnak szánt figyelmeztetéseket kell utólag olvashatóvá tennem a DBben
-
nyunyu
félisten
1252 a nyugat európai kódlap, amiben nincs ő/ű.
1251 a cirill betűs (orosz, szerb, stb.)
1250 a kelet európai.(DOS alatt a 850 volt a nyugat, 852 a kelet európai.)
Ha notepadban ANSI kódolással mentem magyar Win alatt a futtatandó SQL szkriptjeimet, akkor az ó/ű helyesen megy be a Win1250-re állított Oracle DBbe.
Ha default UTF8-on felejtem, akkor pont úgy néznek ki az ékezetek, ahogy a példádban. -
nyunyu
félisten
válasz
Zola007
#20174
üzenetére
Be kéne állítani, hogy a Win kódlapnak megfelelően kezelje az ékezetes stringeket UTF akármi helyett.
Ha jól értelmezem a leírtakat, akkor 'ansi' a Windows mindenkori területi beállításainak megfelelő kódlap. (magyar -> win1250?)
-
nyunyu
félisten
válasz
pmonitor
#20136
üzenetére
De pl az önkiszolgáló kasszák esetén sem értem, hogy miért nem jutott senkinek az eszébe az, hogy legkésőbb a nyugta nyomtatása előtt árucikkenként összesítenék a darabszámot. Csak ezzel mennyi papírt meg lehetne takarítani országosan? Hozzáteszem, hogy ezt nem csak az önkiszolgáló kasszákra, hanem a hagyományos pénztárakra is lehetne alkalmazni. Összefutottam olyan pénztárossal is, aki 14 darab táblás csokit egyesével csippantott le(úgy, hogy én 2 x 7 - es sorba készítettem elő neki). Na, aaz ilyeneket is kiszűrhetné a program. Azért nem mind1, hogy 14 sorba nyomtatja ki a gép, vagy max. 2 sorban.
Ennek nagyon egyszerű oka van: pénztárgép és taxaméter rendelet.
Ez kellően szőrszálhasogató módon specifikálja egy pénztárgép minden műszaki, funkcionális aspektusát, nyugta, számla tartalmát, kinézetét.
Alapvetés: ami egyszer bekerül az adóügyi egység memóriájába, az utólag már nem módosítható, maximum stornózni tudod, de az új tétel, ellentétes árral
Alapvetés2: nyomtatót, vevőkijelzőt az adóügyi egység vezérli, nem kötheted direktben a számítógépre, pláne nem vezérelheted a saját fejed szerint.Nem tudom most milyen adóügyi egységet használnak az áruházak, mivel utoljára 15 éve foglalkoztam ezzel.
Mi anno a BBOX Pocok4 aztán Pocok8 modulját illesztettük az éttermi szoftverünkhöz. (Auchan akkoriban még az eJournal nélküli, 2 példányos mátrixnyomtatós Pocok2-t használta)Ez nagyon leegyszerűsítve úgy működött, hogy soros porton etetted parancsokkal:
- nyugta nyitás: új nyugta generálása, ekkor kinyomtatta a nyugta fejlécet a kötelező elemekkel (bolt neve, telephely címe, cégnév, cég székhelye, dátum, nyugta szám...)
- új tétel: megadtad a tétel nevét, darabszámát, mennyiségi egységét, egységárát, ÁFA kulcsát (A-E) ekkor letárolta a zárolt memóriába és kinyomtatott egy sort.
- ha rontottad, akkor tétel stornót kellett küldeni negatív árral, ez új tételként jelent meg a memóriában, és ismét kinyomtatott egy sort.
- ha végeztél, akkor nyugta zárás parancs, itt megadtad a fizetésmódot (KP, bankkártya, utalvány... Milyen címlet), ekkor összeszámolta az ÁFA kulcsonkénti részösszegeket, végösszeget, visszajárót és a nyugta lábléccel együtt kinyomtatta, valamint lezárta a memóriában a nyitott nyugta rekordot.De ez még az online pénztárgép című őrület 2012-es bevezetése előtt volt, de gondolom a mostani műszaki követelmények is hasonló működési módot írnak le, csak a sallangok változtak. (Pl. nem kell éves zárást nyomtatni, és papíron vagy az éves eJournalt pénztárgép szervizzel CDre kiíratva leadni a NAVnak, hanem az online cucc úgyis lejelenti nyugtánként, legkésőbb a napi zárásnál az integrált mobilneret használva
Vagy 2005-ben még csak 5000 napnyi/műszaknyi nyugtát kellett tudnia eltárolnia egy adóügyi egységnek, 2009 körül ezt 10000-re duplázták, mostani online verzió már 20000 napnyi memóriát követel, közben meg 3-5 évente kidobatják a hardvert új jogszabályi követelmények miatt
Pl. 2006-ban levizsgázott Pocok4-es rendszerünk 2009-ben már nem kapott engedély hosszabbítást, mert "kevés volt a memóriája", cserélhettük mindent Pocok8-ra.
5 év alatt, ha napi 3x van műszak váltás a 24/7-ben működő bolt/benzinkút pénztáránál, az 5x365x3=5475 napzárás.
Átlag sarki boltban évente 300-365 napot zárnak, simán elketyegne 8-10 évig is egy 5000 napos adómemória, mielőtt cserélni kéne benne az epoxival kiöntött EPROMot, de akkor sem a komplett vezérlő egységet...)Eredeti kérdésedre visszatérve:
Program valószínűleg azt csinálja, hogy vonalkód lehúzásnál automatikusan küldi a vonalkódhoz rendelt terméknevet, mennyiséget (1db), egységárat, ÁFAkulcsot új tételként az AEE-nek, aminek nincs mérlegelési lehetősége, új sorban nyomtatja.Másik megoldás az lenne, hogy a pénztáros kiválasztja a terméket, megnyomja a mennyiség gombot, tapiképernyőn bepötyögi/mérleggel leméreti a mennyiséget, aztán enterrel zárja, és ekkor kerülne át a termék neve, ára, pontos mennyissége, egységára, ÁFA kulcsa az AEE-be.
(Pékárú vagy a gyümölcs így működik az önkiszolgáló kasszáknál, amikor rádobod a 3 almát a mérlegre, aztán kiválasztod, hogy jonatán.)De sokkal gyorsabb 7 csokit egyesével áthúzni a vonalkódolvasón, mint a mennyiség gombbal babrálni az érintőképernyőn, meg nem kell a pénztárosnak ide-oda fordulnia közben.
Aldi/Lidl kaliberű cégeknél meg komolyan mérik a pénztárosok gyorsaságát, hány vásárlót szolgálnak ki óránként.
Így náluk fel sem merül, hogy ezzel nyugtánként 3-5-10 centi papírt pazarolnak, lényeg az, hogy hárommal több vásárlót préseljenek át a pénztáron óránként, annyival kevesebb pénztárost kell fizetni.
(Már rég nem néztem, mennyi most egy pénztárgépekbe való 80mmx80m-es hőpapír. 500Ft/guriga? az 500/80 = 6,25Ft/méter.
Nyugtánként 10 centi papír felesleg az 62,5 fillér.)
Új hozzászólás Aktív témák
Hirdetés
● olvasd el a téma összefoglalót!
- One otthoni szolgáltatások (TV, internet, telefon)
- Kínai és egyéb olcsó órák topikja
- sziku69: Fűzzük össze a szavakat :)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Milyen légkondit a lakásba?
- Linux kezdőknek
- Okos Otthon / Smart Home
- S.T.A.L.K.E.R. 2: Heart of Chornobyl
- Mobilinternet
- Kávé kezdőknek - amatőr koffeinisták anonim klubja
- További aktív témák...
- AKCIÓ! ASUS STRIX B650E-E R7 7700 64GB DDR5 1TB SSD RTX 3080 10GB Thermaltake Ceres 500 850W
- Fém, összecsukható és kihúzható fotó állvány eladó
- LG 39GS95UE - 39" Ívelt OLED / QHD 2K / 240Hz & 0.03ms / 1300 Nits / NVIDIA G-Sync / AMD FreeSync
- Bomba ár! Dell Latitude E5550 - i5-5GEN I 8GB I 128GB SSD I 15,6" FHD I W10 I HDMI I Cam I Gari!
- Csere-Beszámítás! AMD Ryzen 7 5700X3D Processzor!
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest