- iPhone topik
- Google Pixel topik
- 45 wattos vezeték nélküli töltés jön az új iPhone-ba
- Apple Watch
- Elérhető az alvási apnoe funkció a magyar Samsung órákon
- Samsung Galaxy A34 - plus size modell
- Xiaomi 14T Pro - teljes a család?
- Motorola Edge 40 - jó bőr
- Egy szenzor, két zoomkamera: újraírta a Huawei a mobilfotózás történetét
- Google Pixel 9 Pro XL - hét szűk esztendő
-
Mobilarena
Új hozzászólás Aktív témák
-
Mi a hipotezisem? Az, hogy sok Java-fejleszto a lambdak ellen van? Hat, szazalekos aranyra nem tudok tippet adni, de latom, ami a netes forumokon zajlik (nemzetkozieken is), es allitasom szerint sokkal kevesbe orul a Java-kozosseg, mint anno a C#-kozosseg. Ez egy korlatolt gondolat reszemrol?
-
#8172
Oppenheimer
nagyúr
modder
#8166
-
martonx
veterán
Három lehetőséged van:
1. A 3 mobil szolgáltató valamelyikével leszerződsz. Az igazán tömeges, leggyorsabb SMS átfutási idejű megoldást ez fogja tudni szolgáltatni, és mindegyiknek van ilyen-olyan interfésze, amin keresztül vezérelni tudod.
2. Szimpla mobiltelefont hozzá tudsz kötni számítógéphez, és azon keresztül is tud menni SMS kommunikáció, de ez percenként néhány SMS-t jelent, mind küldés, mind fogadás oldalon.
3. Vannak kimondottan 3rd party üzenet küldő-fogadó szolgáltatások, mint pl. a Twilio (ez biztos, hogy fogadni is tud) vagy az SMS Cloud (ez lehet, hogy csak küldeni tud), vagy bármi ezekhez hasonló szolgáltató.
-
szombi
tag
Nos, egy alternatíva már van: kimentettem egy weboldal által küldött gzip-elt tartalmát egy "index.gz" fájlba. Ezt a WinRAR és a 7-Zip is ki tudja bontani. Valami egyszerű megoldás(pl. DLL) érdekelne, hogy a dolog mindkét irányba működjön a memóriában is, a háttértár használata nélkül. Használt már valaki ilyet?
Közben -angol- nyelvű leírást is találtam, kérdés hogy ez aktuális-e:
- [rfc-gzip]
- [http compression - standards] -
szombi
tag
Igen, magam szeretnék. Az LZ77 nem olyan nagy cucc, már leprogramoztam párszor. De ha van gzip-re DLL és jó leírás az is jó lesz nekem. A készülő, amatőr letöltésvezérlőmhöz még szerencsére nem kell, ott a HTTP fejlécből kiszedett infó(pl. cookie-k) mindenre elég lesz. A program már kezeli a cookie-kat, belép az oldalra(név+jelszó), meg ki tud jelentkezni...
-
szombi
tag
A "Content-encoding résznél is "gzip" áll. Tessék a teljes HTTP fejléc amit kapok:
HTTP/1.1 200 OK
Date: Sun, 29 Dec 2013 22:45:42 GMT
Server: Apache/2.2.26 (FreeBSD) mod_ssl/2.2.26 OpenSSL/0.9.8x
Set-Cookie: PHPSESSID=4d136c24524999c875f49103a18fc78c; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: public
Pragma: public
Content-Encoding: gzip
Accept-Encoding: compress, gzip
Vary: Accept-Encoding
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-2' -
#7560
Sk8erPeter
nagyúr
modder
#7558
Sk8erPeter
nagyúr
"Code::Blocksot nem ajánlom, mert egyetemen elterjedt, hogy milyen egyszerű és jó, aztán mindenkinek csak baja volt vele, hogy nem működik a debuggolás, meg úgy összességében egy fos."
Ezzel egyetértek
Én használtam is egy darabig, nem maradtak túl jó emlékeim, de lehet, hogy csak rég volt. MinGW-vel azt is össze lehet hozni amúgy debuggolásra, bár lehet vele szerencsétlenkedni. 
Ami erénye, hogy lightweight.A Visual Studiót itt azért sem ajánlottam, mert azt C/C++-programozásra bűn használni a Microsoftos compiler ordas hülyeségei miatt.
A diák úgyis szívni fog vele, aztán tömködi a levlistákat, hogy most mégis mi a szar van, miért van az, hogy otthon működik, de a házibeadón nem (ahol gcc/g++ van).
A Visual Studio nagyon jó C#-programozásra, meg hasonlókra (tényleg az), de C/C++-ra sajnos nagyon felejtős. Kár, hogy nem lehet összehozni normálisan MinGW-vel. -
doc
nagyúr
hat, talan majd egyszer, addig is: sima szokiegeszites CTRL-N es CTRL-P, "rendes" intelligens kodkiegeszitesre az omnicomplete plugin, vagy pont ma kaptam egy tippet: neocomplete, allitolag meg jobb
amargo:
igy van, a vim egy szovegszerkeszto (a programozast, sot a buildet is megkonnyito funkciokkal), nem IDE
-
amargo
addikt
"Ezért absztrakcióra sincs akkora szükség."
Architektúráról hallottál?(#7072) bambano
"szerintem van az oop-nek egy overheadje, ami akkor kezd kifizetődni, ha túl nagy a probléma és már tényleg kell hozzá az oop. hogy minden piszlicsáré dolognál ágyúval lövünk verébre"
Innentől jön be szerintem, hogy ki milyen patterneket ismer. -
bambano
titán
egyik példám, amikor egy jávás programból kellett infót kiszedni. komoly veszekedést kellett tartani a fejlesztőkkel, hogy ne xml-ben adják ki az adatot, mert totál felesleges, elég a csv is.
meg hogy ha tudunk ldap szervert üzemeltetni, akkor használni is fogjuk, ha törik, ha szakad. hogy nincs rá szükség, az nem számít, tudunk ldap queryt programozni, akkor lesz.
szerintem az ilyen hozzáállás miatt lassúak a jáva programok.
(#7071) modder: a getter-setter max. addig nem probléma, amíg megírja helyetted a kódgenerátor. mert egyébként nem az álmok netovábbja gettersettert programozni, favágó munka legalja.
-
#89874944
törölt tag
Igen, jól gondolod. Egy szimulátort készítek. Mobil hálózatokat vizsgálom, felhasználókkal, bázisállomásokkal, linkekkel. Először betölti a hálózati topológiát (vagy saját maga készíti el), aztán magában a szimulációban a felhasználók mozognak, adatot forgalmaznak, bázisállomást váltanak. Egy ilyen szimulációs kör nem tart sokáig, 3 másodperc, csakhogy ebből legalább 60ezer kell. A 3 másodperc 97%-a megy el az adott indexű objektum megkeresésével, ezt szeretném csökkenteni.
Akkor a map value részében konkrétan egy objektum példány legyen?
-
#25954560
törölt tag
+1
az egy dolog h tudsz irni kodot ami lefordul es mukodik is az uj nyelvben, de a nyelv sajatossagait is ismerni kell. sot, ha igazan fontos egy szint utan a teljesitmeny, akkor az optimalizalashoz megtobbet kell rola tudni.
lehet fura kodokat is generalni siman, lattunk mar olyan C kodot, amirol sutott h az iroja elotte sokaig python-t hasznalt tehat illik betartani a hagyomanyokat is, ha azt akarjuk h masok is konnyen olvassak a kodunkat, esetleg javitsak, felhasznaljak (pl opensource vagy siman csak team munka)mod:
figyemen kivul hagytam h rendszergazdai feladatokra kell. arra messze nem a legjobb a c -
Jim-Y
veterán
A Perl neki nem alternatíva? Igazából amikor nekem kellett apache loghoz kódot írni, ami x dolgot megszámolt benne, és mivel a bash szintaktikát nem szeretem, akkor a Perl-hez fordultam, és szerintem az egész programozó-közeli nyelv. Bár tény, hogy debian kapcsán én is úton, útfélen a Python-t hallom...
-
McSzaby
őstag
Hmmm... Ahogy leírtad Python az én nyelvem. Rendszergazda leszek, akarok lenni és a toolok érdekelnek jobban. Szóval szerintem python lesz az én nyelvem. Az lenne még a kérdésem, hogy tudtommal egy nyelv megtanulása után nem nehéz dolog átszokni más nyelvekre, ez igaz, ugye? Illetve még az lenne a kérdés, hogy tudtok esetleg valamilyen doksit, oldalt, leírást mondani, ahol, amiből megtanulhatom az alapokat?
-
#6875
phanfantom
senior tag
modder
#6874
phanfantom
senior tag
Ok, szándékosan nem akartam hosszúra ereszteni a hozzászólásom. Számítottam ilyen válaszokra is, csak nem akartam ezt leírni, hogy ilyet ne... ha szabad kérni
Én úgy vagyok vele, hogy ha valaki nem akar konstruktív lenni(amihez abszolút joga van, ezzel nincs is baj), akkor ne szólaljon meg.
Visszatérve, hogy ne sértődj meg, a "sokat kell gondolkodni" is lehet egy válasz, csak akkor van értelme, ha kifejted mire gondoltál? Ha nem akarod, akkor hagyjuk, ne offoljunk, hidd el, ha nem jön válasz, akkor nem fogom erőltetni itt a témát -
dezz
nagyúr
Volt egy site, amin a korai (európai) PS3-ak félig hw-es, félig sw-es PS2 emulációja alatt futtatott játékprogramok voltak felsorolva. Volt egy olyan mező, hogy kompatibilitás, ott volt jelezve, ha az adott program nem működött megfelelően. Ha nem volt odaírva semmi, az azt jelentette, hogy rendesen fut. Ezt vonta kétségbe az illető személy, mondván, ha nincs odaírva semmi, attól még lehet, hogy fut, csak használhatatlanul lassan, és szerinte a teljesen kompatibilisnek jelzett programok közül is csak kevés a valóban használható. (Persze nem volt PS3-asa, sosem vett volna olyat, mindez csak rosszhiszemű feltételezés volt.) Az én véleményem pedig az volt, hogy teljesen életszerűtlen, hogy ne jelezték volna, ha valami fut, csak éppen használhatatlan. Tehát a teljesen kompatibilisnek jelzett játékok igenis normálisan játszhatóak, azaz igen sok PS2 program játszható a PS3-on. (Más kérdés, hogy később a félig hw-es, félig sw-es emuláció hw-es része is kikerült a gépből, teljes sw-es emulációt nem tudtak megvalósítani, így megszűnt ez a lehetőség.) Itt véget is érhetne a történet, de elkezdődött egy máig tartó hiszti, hogy márpedig én mennyire nem értek hozzá, hogy még azt sem tudom, mi az a kompatibilitás, stb. Pfff... Meg ugye az aláírás. Mindegy, én már sok éve ráhagytam az illetőre az egészet, inkább a közelébe se mentem egy olyan fórumnak, ahol ilyenek a meghatározó elemek. Csakhogy most itt a Ph!-n kezdi ugyanezt...
-
peterszky
őstag
Egyelőre úgy tűnik, hogy elég az egy hátizsák problémát megoldani, ez kész is van (0-1 knapsack, dinamikus programozás megközelítéssel). Viszont itt felötlött bennem, hogy a munkatábla férőhelye igen gyorsan elfogadhatatlan méretűre nőhet, mivel a "kirakandó" összeg lehet akár milliós nagyságrendű is (és a tábla oszlopai ugye 0 -> kapacitásig tartanak).
-
Jim-Y
veterán
Ez kemény, átírtam a scriptet az alapján amit linkeltél:
$loc = get-location
$files = get-childitem -Path $loc -Recurse | where {$_.Length -gt 0}
$length = $files.length
$fileMap = @{}
$duplicates = @()
for($i=0;$i -lt $length;++$i){
$file = $files[$i]
$key = $file.Name +" "+ $file.Length +"byte"
if($fileMap.ContainsKey($key)){
$fileMap[$key] += $file.FullName
} else {
$fileMap[$key] = @($file.FullName)
}
}
foreach ($item in $fileMap.GetEnumerator()) {
if($item.Value.Length -gt 1){
$duplicates += $item.Name+":"
$duplicates += $item.Value
$duplicates += "`n"
}
}
$duplicates > fileMap.txtAmi eddig 45 percig futott most 15 mp volt
Ami eddig 22 mp volt az most 460 msMég leellenőrzöm, hogy ugyanazt az eredményt adja-e, de ránézésre igen
-
bambano
titán
nekem nem az a problémám vele, hogy van-e olyan fórumtárs, aki rászánja az idejét, mert ezt mindenki maga döntse el.
hanem az, hogy más munkáját beadni egyrészt törvénytelen, másrészt meg a nagy ösztöndíj versenyben esetleg megelőzi azt, aki maga szenvedte ki a háziját, így igazságtalan is. -
#95904256
törölt tag
Igen, assembly. Az már biztos, hogy az A=(H-L)*R kódjával van a probléma, mert az A=(H-L)+(H-L)+(H-L)+... képlettel is az A=(H*R)-(L*R) eredménye jött ki.
A kód az alábbi:
XOR EBP,EBP
MOV ECX,4096
CLC
BIGSUB: MOV EAX,[L+4*EBP]
SBB [H+4*EBP],EAX
INC EBP
LOOP BIGSUB
XOR EBP,EBP
XOR ESI,ESI
MOV ECX,4096
MOV EBX,[R]
BIGMUL: MOV EAX,[H+4*EBP]
MUL EBX
ADD EAX,ESI
MOV [H+4*EBP],EAX
MOV ESI,EDX
INC EBP
LOOP BIGMUL -
-
Igen, bár én ezt elvont formában értettem.
A kódból generált XML doksiknak még kevesebb értelmét látom, mint a többinek. Én úgy értettem, hogy a kód fejlesztőknek szól és úgy kell megírni (komment nélkül), hogy abban el lehessen igazodni, jól lehessen olvasni. Ehhez kellenek olyan szakik, akik nem csak működő, de olvasható kódot is tudnak produkálni. Jól felépített, lazán csatolt, stb."Itt már nem biztos, hogy az automatikusan generált osztálydiagram elég, mert az nem fog semmit jelenteni a többi fejlesztő számára a lib használatát illetően. "
Ebben igazad van, ez tényleg kivétel, itt nincs mit tenni, valahogy le kell írni.
A különböző UML diagramokat valóban tudnia kell olvasni egy fejlesztőnek, mert lehet rá szükség, Ezt ki is felejtettem az előbb. Jó is, hogy írtad.
"Ami igazából a mondanivalóm, az az , hogy az UML teljesen alkalmas ezen megbeszélések alkalmával információátadásra, ideiglenes dokumentációként."
Abszolút így van. Ideális esetben mindenki érti és könnyű így megbeszélni, hogy közben táblán, bárhol rajzolgatunk. Csak sajnos sokszor a jelmagyarázattal kell kezdeni, ami elég időrabló.
A dekompozíciós részben is egyet értek, az iterációs, de még inkább az agilis fejlesztés is végül úgyis visszatér az adatokhoz, de ha eleve aspektus orientáltan kezdünk hozzá, akkor hamarabb lesz bemutatható funkció halmaz, mint az első körös csak tervezéssel. Sajnos itthon ez nem elterjedt még sok helyen.
-
Teljesen érthető álláspont. Jó néha a nézeteket ütköztetni, mert abból lehet tanulni.
Én sem 1-2 fős csapatokról beszéltem, bár ez nem jött le abból, amit írtam. Én a következőket alkalmazom - természetesen úgy, hogy ma Magyarországon nem gyakorlat a vízeséstől eltérő projektvezetés, hiszen legtöbbször előre rögzített doksikért fizetnek, azok jelentik az első mérföldköveket és azokat lobogtatják másfél évvel később is bőszen.
"Persze a dokumentáció mennyiségének növekedésével a szoftverfejlesztés időtartama kitolódik."
Ezért látom én úgy, hogy a minimális jelenthet 0 közeli állapotot is ezeknél, vagyis a kód maga a dokumentáció. Ezt a fenti modell tükrében nem lehet kivitelezni, ám sok doksi gyártható utólag, menet közben is, generálva. A lényeg, minimális legyen a fejlesztők által dokumentálásra fordított idő, így az UML jó része is kimarad a fejlesztőknek - ez legyen a projektvezető vagy rendszerszervező.
Olyan projektnél, ahol modulokat építünk egybe, írtam is, hogy a kapcsolódási pontokhoz kell valamiféle támpont, az pedig lehet UML is akár. Minimális áldozat, de előre legyártani ezt is éppoly veszélyes, mint egy rendszertervet. Jobb pár meetinget tartani a többi fejlesztővel és kódba belemenni, esetleg már bemutatható, legalább mock interfészekről beszélni. Rengeteg példa van arra, hogy a rendszer változott, csak a doksikban nem vezették át.
A használati eset és az activity diagramm legyen a projektvezető dolga szintén. Nem fogom ezzel a fejlesztőket terhelni, mert nekik ehhez nem sok közük van közvetlenül. Ez max. arra jó, hogy csekkolni lehessen, hogy a feladatok hol tartanak, mi van még, de erre a prototípusok, release-ek is megfelelnek és abból legalább lát is valamit az ügyfél.
Class és szekvencia utólag generálandó szerintem, különben erőforrást köt le huzamosabban, ami nem jó. Igen, erre gondoltam, hogy ez lényegesen eltérhet a kiindulási állapottól. Szerintem több modul esetén is simán működhetnek a mock interfészek vagy a sűrű release-ek. Ezek specifikációját viszont nem feltétlenül szükséges UML-ben megadni.
"A diagramok egy része az implementáció megkezdése előtt születik, más részük közben, megint más részük utólag. Természetesen elkerülhetetlen a változás, mert nem lehet minden eshetőséget lefedni a fejlesztés során. "
Én is így látom. Előre nem lehet kőbe vésni még nem látható dolgokat. A fejlesztő, architect nem jós.
"Sajnos rossz gyakorlat az, hogy a dokumentációt fejlesztés után készítik el, és a fejlesztés gyakorlatilag ad-hoc módon történik: a fejlesztők egymás között ledumálják ki mit csinál, aztán probléma van, amikor össze kell hegeszteni a dolgot egy egésszé."
Nem lehet egyenlőséget tenni az ad-hoc fejlesztés és az utólag dokumentálás között. Ismét megemlítem, hogy a legjobb dokumentáció maga a kód - abban nincs és nem is lehet összebeszélés, háttéralku. Ilyet egyébként sem lehet megengedni, de egy class diagram mégis akkor lehet teljes, ha a kész/félkész kódból generáljuk.
Amit itt írsz, pont a kis csapatokra vonatkozik (leosztják egymás között a feladatokat, megy a susmus, stb.), de nagyobbaknál is jól működhet az, hogy nem egy bizonytalan és régi rendszerterv és UML-ek alapján fejlesztenek, amiket nem tartanak karban, hanem az igények szerint és a haladást maga a termék jelenti. Így az ügyfél is hamarabb lát belőle valamit és így jobban is tud gondolkodni, mint ábrák alapján.
"El kell fogadni, hogy a dokumentáció a fejlesztés szerves része, és mint említettem, nagyobb projekteknél a kommunikáció folyamatossága érdekében elkerülhetetlen rossz vagy éppen jó."
A régi szemlélet szerint igen. A vízesés modellben máshogy el sem lehet képzelni a fejlesztést, de maga a modell eleve csak rossz példaként lett régen is megemlítve, amikor felkapták. Ha a levelezést nem tekintjük dokumentációnak, akkor a kommunikációhoz nincs szükség rendszertervre, UML-re és egyebekre. Nem kell kizárni, mert lehet, hogy azt valaki annyira vágja, hogy azonnal lát mindent, de sok esetben a kód, az alkalmazás sokkal hasznosabb forrás.
Nem mondom, hogy ez a szuper és ultimate módszer, meg így kell mindenkinek, de én így látom. Az agilis és egyszerű, letisztult fejlesztést részesítem előnyben és ez nem csak idea.
Egy példa még a végére:
Régi vesszőparipám az, hogy sok projekt az adatbázis megtervezésével indul, holott ez a rész 90% eséllyel szinte azonnal megváltozik. Ha a "dekompzíció" és a funkciók mentén haladunk, akkor elemi feladatokkal gyorsabban lehet bemutatható alkalmazást készíteni, mint a legnagyobb falattal szöszmötölni.Természetesen ehhez befogadó projektvezetés és ügyfél is kell.
Hű, de hosszú lett. bocs.
Én használtam is egy darabig, nem maradtak túl jó emlékeim, de lehet, hogy csak rég volt. MinGW-vel azt is össze lehet hozni amúgy debuggolásra, bár lehet vele szerencsétlenkedni. 
Asztali is, meg mindent tud, amit szeretne. 
Új hozzászólás Aktív témák
Hirdetés
● olvasd el a téma összefoglalót!
- IKEA Format lámpák eladóak (Egyben kedvezménnyel vihető!)
- MacBook felvásárlás!! Macbook, Macbook Air, Macbook Pro
- Azonnali készpénzes nVidia RTX 2000 sorozat videokártya felvásárlás személyesen / csomagküldéssel
- Csere-Beszámítás! Olcsó Gamer laptop! MSI Cyborg 15 . I5 12450H / RTX 4050/ 16GB DDR5
- HP 200W (19.5V 10.3A) kis kék, kerek, 4.5x3.0mm töltők + tápkábel, 928429-002
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest