-
GAMEPOD.hu
Új hozzászólás Aktív témák
-
válasz bambano #2155 üzenetére
#include <stdio.h>
FILE *be;
char *t[256];
int i,c;
int main(int argc, char *argv[]) {
for(i=0;i<256;i++) t=NULL;
t['á']=''a''';
t['A']=''A''';
be=fopen(argv[1],''r'');
while(!feof(be)) {
c=fgetc(be);
if(t[c]==NULL) {
printf(''%c'',c); } else {
printf(''%s'',t[c]); }
}
fclose(be);
return 0;
}Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Jester01
veterán
válasz bambano #2156 üzenetére
1. A változókat gondolom a main-be lokálisan akartad tenni
2. Mint említettem az unsigned char cast szükséges. Pl. x86 linuxon gcc 4.0 esetén (most ez van kéznél) a char az signed és emiatt nem mûködik a progi.
3. az feof tesztelés így nem jó, túlolvas. Egyszerûen az fgetc visszatérési értékét kell EOF-fal összehasonlítani.
Bocs a kötözködésért.
Még egy apró gondolkoznivaló a kérdezõnek: vigyázz milyen kódlapot használsz.Jester
-
bdav
őstag
válasz bambano #2154 üzenetére
str2t majd a hívó fél, ha változót adsz paraméterül akkor ciki lenne ha felszabadítaná, ha nem akkor abban nem vagyok biztos
realloccal igazad van, de C-ből a beépített függvényekből elég keveset tudok fejből (amikor tanultam nem kellett, azóta meg nem programozok C-ben)10 féle ember van a világon. Aki ismeri a kettes számrendszert és aki nem. ''A név nincs hosszabb páncélszekrény''
-
-
Jester01
veterán
válasz bambano #2159 üzenetére
1. nem mindegy, hogy mit szokik meg.
2. Nem az fgetc-nél kell a cast, az valóban úgy van ahogy írtad. Hanem a táblázat feltöltésénél, ahol karakter konstansot használsz. Itt, ni:
t['á']=''a''';
3. Nekem megy. Ellentétben a tieddel, mert az - mint említettem - túlolvas és aztán mínusz egyet (EOF) használ tömb indexnek.
[Szerkesztve]Jester
-
Tamy
senior tag
válasz bambano #5599 üzenetére
Köszönöm ismét a segítséged, innen valamiért kimaradt, de már úgy volt. Még Jester01 javasolta a router topicjában, sajnos így sem jó.
Most ha elindítom ezt adja:root@Tamy-router:~# /etc/config/limit start
+ insmod cls_fw
+ insmod cls_u32
+ insmod sch_htb
+ insmod sch_sfq
+ insmod sch_ingress
+ insmod act_police
+ DEV=eth0.1
+ LIMIT_IPS=192.168.2.100
+ LIMIT_DOWN=200
+ LIMIT_DOWN_BURST=400
+ LIMIT_UP=400
+ case "$1" in
+ echo -n 'Starting bandwidth shaping: '
Starting bandwidth shaping: + start
+ tc qdisc del dev eth0.1 root
RTNETLINK answers: No such file or directory
+ tc qdisc add dev eth0.1 root handle 77: htb
+ tc class add dev eth0.1 parent 77: classid 77:1 htb rate 20000kbit
+ tc class add dev eth0.1 parent 77:1 classid 77:10 htb rate 200kbit ceil 400kbit prio 2
+ tc qdisc add dev eth0.1 parent 77:10 handle 78: sfq perturb 10
+ tc qdisc add dev eth0.1 ingress
+ tc filter add dev eth0.1 parent 77: protocol ip prio 2 handle 80 fw flowid 77:10
+ tc filter add dev eth0.1 parent ffff: protocol ip prio 1 handle 79 fw police rate 400kbit mtu 6k burst 6k drop
+ for ip in '$LIMIT_IPS'
+ iptables -t mangle -I PREROUTING -s 192.168.2.100 -j MARK --set-mark 79
+ iptables -t mangle -I POSTROUTING -d 192.168.2.100 -j MARK --set-mark 80
+ echo done
done
+ exit 0Viszont mint már korábban is beszéltük a stop sem oké teljesen (bár ha belegondolok az annyira nem lényeg):
root@Tamy-router:~# /etc/config/limit stop
+ insmod cls_fw
+ insmod cls_u32
+ insmod sch_htb
+ insmod sch_sfq
+ insmod sch_ingress
+ insmod act_police
insmod: can't insert 'act_police': File exists
+ DEV=eth0.1
+ LIMIT_IPS=192.168.2.100
+ LIMIT_DOWN=200
+ LIMIT_DOWN_BURST=400
+ LIMIT_UP=400
+ case "$1" in
+ echo -n 'Stopping bandwidth shaping: '
Stopping bandwidth shaping: + stop
+ tc qdisc del dev eth0.1 root
+ iptables -F -t mangle
+ echo done
done
+ exit 0Egész életemben azon gondolkodtam, hogy kéne valamit dolgoznom. Ezért aztán a végén nem is maradt rá időm.
-
-
addikt
válasz bambano #5689 üzenetére
Ja igen, bocsanat, windowson akarom s ha a DB-s megoldas lenne, akkor mssql-t hasznalnek, azt ismerem.
azt, hogy kiírod-e fájlba vagy memóriában tárolod, szerintem az dönti el, hogy hol keletkezik az adat
Nem igazan tudom mire gondolsz, sok programozasi tapasztalatom nincs eddig, kisebb progikat es scripteket irogattam csak.
Ja es a lassu megis mit takar idoben?
Mondjuk 5 millio sornal pl.[ Szerkesztve ]
-
Jim Tonic
nagyúr
válasz bambano #5680 üzenetére
Nem feltétlenül a suli a baj. Ma már csak a BME szül viszonylag megbízhatóan jó programozókat, a többi iskolából kb. egyforma tudással jönnek ki a diákok.
Tény, hogy a programozóknak jobb a piaca, mint a rendszergazdáknak. A fizetésük is magasabb, nagy általánosságban. A helyében rágyúrnék valamire, aztán abban próbálnék elhelyezkedni. Sokat segíthet egy-egy tanfolyam is, valamilyen MS, Cisco, stb oklevél sokat dob. Azt nem tudom, mibe kerülnek most.
Alcohol & calculus don't mix. Never drink & derive.
-
Jim Tonic
nagyúr
válasz bambano #5701 üzenetére
A kivitelezés sebességére gondoltam. Én pl. hülye lennék írni egy mySQL szervert, se időm, se kedvem, se tapasztalatom hozzá. Ezerszer többet szívnék vele, minthogy keressek egy ingyenes megoldást. Pl. múltkor találtam ingyenes mySQL szervert is, bár azokra sok dolgot nem bíznék.
amargo: Simán igazad lehet. Már ha egyáltalán egyre gondolunk, az ELTE-re.
[ Szerkesztve ]
Alcohol & calculus don't mix. Never drink & derive.
-
Jhonny06
veterán
válasz bambano #5706 üzenetére
Pont ez a lényeg, hogy nincs ilyen, hogy jobb. Mert nem ad annyit egyik hely se, hogy ilyen megtörténhessen. A jó szakemberek a saját akaratuk miatt azok és nem azért, mert oda jártak, ahova. Ezzel nem azt akarom mondani, hogy GDF == BME, de a rangsorban lévő mondjuk első 3-4-5 hely (korábban leírtak) hozzávetőlegesen ugyanaz, nincsenek nagy eltérések.
"bmf vagy ppke jobb, mint a de?"
DE mint Debreceni Egyetem?
[ Szerkesztve ]
-
Karma
félisten
válasz bambano #6034 üzenetére
Végülis kiskanállal is lehet gödröt ásni... De ha már jeszi fizet a T-Mobile tömeges SMS küldéséért, akkor valószínűleg nem megoldás a telefonkötögetés Főleg ha egyébként a küldést már megoldotta ezek szerint, csak Linux lokál probléma van.
Kernelt nem akarsz vele fordíttatni?
jeszi: Egyébként én is message queue párti vagyok, az ActiveMQ-t például össze lehet kötni Perllel. Csak egy kicsit bonyolultabb Perl kód kell, amiből nem spawnolsz olyan sokat.
[ Szerkesztve ]
“All nothings are not equal.”
-
Karma
félisten
válasz bambano #6037 üzenetére
Az ActiveMQ vegulis csak egy pelda volt, masok is szoktak Perllel csevegni...
Az adatbazis trigger cseles megoldas, tetszik :-) Munkahelyi artalom, hogy csak nagy LEGO kockakkal tudok gondolkodni, amikor szerveroldalrol van szo.
A kernelt meg nyilvan azert irtam, mert egy desktop alkalmazassal ilyen munkat vegeztetni szvsz eros. De izles dolga igazabol - jelen esetben ugyis mindegy.
[ Szerkesztve ]
“All nothings are not equal.”
-
modder
aktív tag
válasz bambano #6279 üzenetére
Igen, ez hirtelen eszembe sem jutott.
Van olyan ismerősöm, aki természettudományi karon van, vagy biomérnöknek tanul, már tőlük is megkövetelik, hogy legyen fogalmuk a programozásról. És ők is kiszenvedik magukból a házikat.
Ezt csak azért mondom, mert nem tudom, mit tanul az illető hozzászóló, de ha nem informatikát, akkor is illedelmes lenne megpróbálni megoldani magától.Amikor valaki azzal kezdi, hogy nem tudja hogyan kezdjen hozzá, az már annak a következménye, hogy egész félévben beletojt a tárgyba. -- Aztán ilyenkor jönnek ezek a hozzászólások, amikor közeleg a határidő, és már nincs idő belerázódni
-
cucka
addikt
válasz bambano #6385 üzenetére
a program szerzői jogai közül a tulajdonjogról nem lehet lemondani, ergo ez marad a szerzőnél
Szerintem ez nem így van. Ha egy cég alkalmazottjaként írsz egy szoftvert, a tulajdonos a cég lesz. Amiről nem lehet lemondani, az a szerzői jog.
Nem vagyok jogász, szóval ha tévedek, örülnék, ha egy szakember kijavítana.[ Szerkesztve ]
-
P.H.
senior tag
válasz bambano #6952 üzenetére
A TSP egy gráf bizonyos pontjainak (azaz részgráfjának) bejárása, a gráf pedig adott jelen esetben is: pl. úgy, hogy két pont közötti adott a legrövidebb úttól (2D távolság mint közvetlen összeköttetés) a leghosszabbig (végtelen távolság) az összes él. Így nem kell utat "építeni".
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
válasz bambano #6956 üzenetére
Ponthalmaz, amelyeket összeköthetünk bármilyen módon: egyenes szakasszal összekötve megvan a legrövidebb távolságuk, de bármilyen más módon összekötve őket (akár más pontokon keresztül, akár a monitort körbekerülve egy görbével) is létezik él, azaz végtelen (élszámú) a gráf.
Ebből - mint a feladvány is mondja - célszerű azt a részgráfot kiválasztani, amiben minden gép minden géppel közvetlenül össze van kötve, ez már véges. "Az lenne a feladat, hogy adott pontokat(csomópontok, node) úgy kéne összekötni, hogy egy gyűrűt alkossanak." Ez nem bonyolult feladat, n node-ra:
pl. 1 <-> 2 <->...<-> n-1 <-> n <-> 1
Olyan gyűrűt keresni viszont ebben a részgráfban, amely nem metszi önmagát, és csak node-ban tudja egyáltalán (nyilván), ez NP-teljes.#6958: ezért mondtam, hogy a metszés jó ötlet. Nem ok nélkül ragaszkodik hozzá
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
válasz bambano #6960 üzenetére
A "Szerk"-edre mondtam gyakorlatilag, hogy nem ez bonyolult (ha a bemeneti pontok fokszáma 2):
1 <-> 2 <->...<-> n-1 <-> n <-> 1
Ha mindegyik mindegyikkel össze van kötve (a pontok fokszám n-1), és abból kell kiválasztani a gyűrűt, az már az. Ha pedig nincsenek előre definiáltan összekötve, akkor végtelen a fokszám: bármerre indulsz el, eljuthatsz bármely más ponthoz (ezért célszerű összekötnünk mindent mindennel közvetlenül és ebből kiindulni: miért indulnál el pl. az ellenkező irányba? Az csak egyrészt hosszabb élt eredményez, és a fenti triviális megoldást).
A 'legrövidebb' pedig vonatkozik a szélsőséges esetekre: egy egyenesre eső pontokra, szimmetrikus bináris fákra, stb.Nyilván ha van egy bármilyen (nem szükségesen legrövidebb) megoldásod, ott már lehet 'törni' pl. a metszésnek köszönhetően. Ez ugyanaz, mint kiindulni 2 pontból és mindig a legjobb helyre beilleszteni a következő pontot (ez sem polinomiális, mert n pontos gyűrűnél legrosszabb esetben n-1! próbát jelent - ha a próba mindig metsz a meglevő gyűrűvel az említett szélsőséges esetekben ).
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
McSzaby
őstag
válasz bambano #6999 üzenetére
Python lesz az én nyelvem. Találtam egy oldalt, ahol magyarul szépen magyaráznak. PHP alapjaim vannak, de szerintem lesz még kérdésem bőven. Pythont megtanulom utána belemászok a C-be... Mondjuk nem tudom mennyi időbe fog telni eljutni egy "közepes/haladó" szintre, de egyszer csak-csak.. Köszönöm a segítségeket!
#ThankYouSirAlex #ThankYouLouis
-
Jim Tonic
nagyúr
válasz bambano #7041 üzenetére
Nem úgy értettem, hogy a webről is az optimalizálatlansága miatt szorulna szorulna ki. Egyszerűen, ahová teljesítmény kell, ott sokan kritizálják. Tény és való, hogy pl. egy játékprogramot komoly kompromisszumokkal tudnál benne megírni. Ugyanakkor az is igaz, hogy az SAP app serverei JAVA-ra (is) épülnek. Webre eléggé terjed a .NET, a LAMP meg inkább az egyszerűsége miatt kedvelt. Hozzáteszem, én csak desktopra dolgoztam JAVA-val. Érdekes nekem anno a suliban a JAVA-t kellett ész nélkül tolnom, talán ezzel a nyelvvel foglalkoztunk a legtöbbet, de nemrég meglepődtem, hogy az egyik egyetemen mérnök infón alig esett róla szó BSc.-n.
#7040: A GUI tenyleg lassu, de ez a platformfuggetlenseg ara, nem kell benne desktop appot irni es kesz. Erről van szó, azaz mégsem jó feltétlenül ezt ajánlani kezdőknek.
[ Szerkesztve ]
Alcohol & calculus don't mix. Never drink & derive.
-
modder
aktív tag
válasz bambano #7051 üzenetére
Bevallom, hogy elfogult vagyok a Java irányába, de nem a performancia tekintetében. Mindkét nyelv ugyanazon a módszeren alapul: virtuális gép, JIT. Mindkét platformon rohadt okos emberek dolgoznak, hogy jobbá tegyék, így szerintem sebesség tekintetében nem lesz nagy különbség, aminek örülök is, hogy tudtál igazolni.
De hogy még árnyaltabb legyen a helyzet a két nyelv közötti sebesség tekintetében, azt írja a péper, hogy Java 2 SE 1.3-mal mértek, ami 13 éves. A 13 év alatt mind a Java, mind a .NET hatalmas fejlesztéseken ment keresztül, úgyhogy nem lennék meglepve, ha a 16%-os különbség 0 közelébe konvergálna. Jó lenne ezeket a teszteket ma is lefuttatni.The Java HotSpot Virtual Machine is Sun Microsystems' virtual
machine for the Java 2 Platform Standard Edition since version
1.3. Java HotSpot VM consists of two basic components: the
runtime and the compiler. -
martonx
veterán
válasz bambano #7051 üzenetére
Félreértettél. Én nem tisztán a futásidőkről beszélek. A komplett hardver kihasználásról. Egyszerűen a .Net nem annyira erőforrás pazarló, és itt nem is feltétlenül a processzor időt, hanem leginkább a memória használatot, aszinkron futási mód fejlettségét értem alatta.
Vajon miért van nagyon kevés java-s publikus hoszting? Mert míg egy néhány GB ram-os gépen több tucat asp.net-es alkalmazást futtathatsz, addig örülsz ha ugyanazon a vason elfut néhány jvm, és akkor még nem beszéltünk arról, hogy azok külön konténerekben vannak-e, meg összeakadnak-e, meg milyen időközönként fogy el a memória.
Távol álljon tőlem bármiféle java - .net flame, valaki kérdezett, én csak leírtam az eddigi tapasztalataimat. Nem volt célom senki lelkébe gázolni.Én kérek elnézést!
-
#25954560
törölt tag
válasz bambano #7067 üzenetére
ejgen, en is pont ezt a hasonlatot szoktam felhozni. nem kizart h tenyleg megszokasbol irodik a java kodok nagy resze, azert hatekonytalan. csakhogy nalunk fontos a sebesseg, vannak azert folyamatosan torekvesek az optimalizalasra. de nem az en asztalom, nem mennek bele.
-
modder
aktív tag
válasz bambano #7067 üzenetére
Ez a "túldizájnoltság" szerintem is probléma, és ettől tényleg lehet lassú valami. A Java EE-nek egyébként is az az alapelve, hogy minden specifikáció, minden egy interfész, aztán olyan implementációt teszel mögé, amit akarsz lásd: OpenJPA, Hibernate, Eclipselink JPA-ra; többféle servlet container; JSF implementációra Mojarra, Myfaces; JDBC connectors; És ezeknek persze együtt kell működniük.
Ez egyébként szerintem nagyon jó dolog, mert választhatsz, ha az egyik nem váltja be az ígéretet, akkor ott van a másik. A különböző implementációk versengenek egymással, így elvileg egyre jobbakká válnak. Sok opensource projektnél elég komoly QA is van. És szerintem nem is itt veszik el a teljesítmény: nem a Java EE service API-k és service providerek közötti vékony interfészen, hanem a service providerek implementációjában, és a programozók hozzá nem értésében, és a túlzott absztrakcióban.
Utóbbira példa, amikor belenéztem az activiti.org kódjába, és végigdebuggoltam egy adatbázis lekérdezést. Na ott fogtam a fejem. Volt benne struktúra bőségesen is azért, hogy az adatbázist el lehessen érni szimpla JDBC kapcsolaton keresztül, támogassa a Spring és JTA tranzakció kezelést stb... Na azt már egészségtelen volt látni és ki tudja, hogy egy olyan, sokak által használt könyvtár, mint a Hibernate nincsen tele hasonló absztrakciókkal?
Állandóan azt sugallja mindenki, hogy milyen jó az absztrakció, mert akkor az interfész mögötti implementációt mindig le lehet cserélni, és nagyon sok végfelhasználói program is ebben a szellemben készül el. Ez az egész attitűd a Java programozóknál pont lehet, hogy a Java hasonszőrű hozzáállásából ered. Nem is alaptalan hülyeség, mert a fenti, activiti.org-os példánál haszna tényleg van: van aki Springes alkalmazásként akarja használni, van aki Java EE alkalmazásba integrálva, van aki szeretne JTA-t használni, van aki nem... végfelhasználói alkalmazásoknál pedig olykor-olykor előfordul, amikor különböző rendszereket kell összekötni.
A másik oldalon mi van .NET-ben? Minden meg van írva a Microsoft által, ritkán kell külső library-ket használni. Az ember, amikor fejleszt, tudja, hogy mikor mihez kell nyúlnia, és tudja, hogy vagy azt a komponenst használja, vagy nagyon nyomós ok/különleges igény kell ahhoz, hogy valamilyen külső libet használjon. Amit pedig használ, az nem fog változni. Ezért absztrakcióra sincs akkora szükség. Nekem legalábbis ez az érzésem, még nem fejlesztettem .NET-ben.
Bár ezzel még nem írtam le a Javát, a fentiek miatt én maximum 5-10% sebességvesztést mondanék .NET-tel szemben, de ez csak intuíció.
A másik, hogy a Java-t tudni kell használni. Nem mindegy, hogy az ember LinkedList-et vagy ArrayListet használ orrba-szájba, nem mindegy, hogy Hashtable vagy HashMap. Nem mindegy, hogy mekkora függvényeket ír, mert a JIT csak függvény szinten fordít, ha ránéz, és látja, hogy ez biztony 200 sor, hülye lesz lefordítani . Nem mindegy milyen String kezelő függvényeket használ. Nem mindegy, hogy fűz össze Stringeket. Nem mindegy, mekkora objektumokat használ: például kis méretű osztályokat lehet orrba-szájba példányosítani, majd hagyni felgereblyézni a garbage collector által, mert erre van külön optimalizáció a Hotspot VM-ben. String kezelés nagyon sokat el tud venni alapjában véve.
Akkor például, ha valaki JPA-t használ, hajlamos (én hajlamos vagyok) nem figyelni, hogy valójában hányszor fog az adatbázishoz fordulni a provider, amíg ez nincs optimalizálva, bizony előfordul, hogy egy oldal lekérdezés alatt több 10-szer is. Hogy van beállítva a cache, lehet, hogy a memória felét a Hibernate akárhanyad szintű cache-ében tárolt adatbázis objektumok alkotják.
Akkor aki JSF-et használ, nem árt belegondolni, hogy mennyire akar külső komponens library-ket használni, mint az Icefaces vagy Primefaces. Ezek nagyon szépek, sokat tudnak, de megvan az ára is sokszor: a komponensek állapota minden felhasználói sessionre egyedileg tárolódnak, így elég sok memóriát meg tudnak enni. (azt hiszem talán ASP.NET Webforms-szal is ez volt a probléma?) Figyelni kell, hogy mit tárolunk SessionScope beanekben, mert betolni a fél adatbázist memóriába, és ott tartani a user session végéig azért, hogy feltöltsünk egy datatable-t, amit fél percig néz a user, nem túl okos ötlet. Ugyenez vonatkozik JPA-ra is: Eager fetch-csel óvatosan, nehogy pár entitásért berántsa a fél adatbázist memóriába a tranzitív eager fetch propertiken keresztül.
Na ez csak pár dolog, ami eszembe jutott, és ami könnyen problémákhoz vezethet. Ha performance probléma van, nem egyből a nyelvet kell okolni, hanem profiling-ot kell alkalmazni, meg kell nézni, hogy mi lehet a szűk keresztmetszet. A fent leírtak közül bármi okozhat rohadt sok memóriazabálást, lassúságot.Na még egy gondolat, visszaugorva az esetlegesen lassú vagy optimalizálatlan service providerekhez. (mint Hibernate). Vajon jogos-e magát a nyelvet lassúnak kikiáltani úgy, hogy nem közvetlenül a nyelv lassú, hanem a köré épített platform? Szerintem jogos, elvégre a Java EE maga ezek a library-k, de nem egyértelmű, hogy ők okolhatóak ezért. Ott van például a korábban említett Cassandra, Neo4j vagy éppen a HBase, Hadoop platform, mind Javában vannak írva, és köszönik, nagyon jól megvannak és gyorsak. Jobban utána kéne járni a lassúság "sztereotípiának", hogy mi lehet az oka, és mennyi igazság van benne.
-
Atos23
senior tag
válasz bambano #7095 üzenetére
Köszi az ötletet, tényleg jók! Annyit kifelejtettem, hogy a tanárom mondta, mivel programtervező informatikus a képzés, legyen kicsit közelebb a .net programozáshoz, mint az elektronikához.
Persze bármilyen tárgyból írhatok, szerencsére voltak hardveres óráink, bár sajnos a legtöbb tanár kizárólag szoftveres érdeklődésű.Az eddigi ötleteim:
- Rádióamatőr állomásvezérlő program, Winformok, soros porton keresztül morzézik is ha kell
- Távirányítós autó formájú "robot". Benne Raspberry pi-féle mini számítógép, futó grafikus OS-el. A gép wifivel kimegy netre. A Raspberryre távoli asztallal csatlakozom, és azon keresztül futtatom a léptetőmotor vezérlő programot. Internetes távirányítós autó, saját szoftverrel.
[ Szerkesztve ]
-
válasz bambano #7095 üzenetére
vannak SoC megoldások a célra.
aquaero 5 LT
aquaero 5 Pro
Corsair Link -> ez lehet csak ambientet tud
mCubed tBalancer miniNG
mCubed Tbalanced classic
mCubed Tbalancer BigNGa miniNG olyan 10k, a többi jellemzően 20-25 körül mozog. de ez itt ebben a topikban nagyon off.
Don't dream it, be it. // Lagom amount.
-
martonx
veterán
válasz bambano #7128 üzenetére
Én jellemzően TFS-ezek, pláne mióta felhős, és ingyenes lett és marhára nem hype, vagy életkor miatt, hanem tapasztalataim szerint ez jött be eddig legjobban, és mert Visual Studioval fejlesztek (Eclipse-el és XCode-al is eggüttműködik) így megtehetem. Amikor néha Netbeans-ezek, olyankor Bitbucket-ozok, vagy projekt függően néha Github.
Azért a javasolt Github is letett már ezt-azt az asztalra, és a Bitbucket is rengeteget tud egy szimpla SVN-hez képest.
De nem akarok én senkit rábeszélni semmire, SVN is elmegy egynek. Hülye autós hasonlattal élve: ha kipróbálhatsz egy ősrégi opel-t, vagy egy új bmw-t, akkor miért kezdenél az opel-lel? Másrészt, amíg nem próbáltad az ősrégi opel-t, addig nem biztos hogy fogod értékelni az új bmw-t, szóval akkor visszavonom a javaslatomat, kezdje mindenki az SVN-nel. PeaceÉn kérek elnézést!
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- A Gigabyte is visszaveszi alaplapjainak alapértelmezett tuningját
- Villanyszerelés
- Politika
- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- A Honor és a Huawei uralja a kínai mobilpiacot
- Ezek a OnePlus 12 és 12R európai árai
- Luck Dragon: Asszociációs játék. :)
- Projektor topic
- Linux kezdőknek
- YouTube
- További aktív témák...