több gombos egér + fejlesztés

Sziasztok, így Karácsonyra szemezgettem a több gombos egerekkel.

Érdeklődnék hogy ki mire tudja/szokta használni a plusz egér gombokat munka vagy fejlesztés vagy böngészés közben? Ami könnyebbé teszi az életét?

Van vkinek erre jól kialakult bevált szokása ötlete? :)

ui: én leginkább eclipse ide, java, linux világban mozgok.

Hozzászólások

Szerintem a másik irányban kellene felülni a biciklire: https://themouseless.dev/

Grafikusnál még elmegy, hogy egyik keze az egeren, a másik meg a billentyűzeten. Habár Dvorak alkotott egykezes kiosztást, valahogy nem vált divatossá: https://en.wikipedia.org/wiki/Dvorak_keyboard_layout#One-handed_versions Az állandó váltás az egér és billentyű között pedig megöli a produktivitást. Talán jobb lenne egér nélkül... de ez csak az én véleményem.

Böngészésnél is ki lehet váltani az egeret, például: https://vimium.github.io/ Ha órákon keresztül kell böngészőben dolgozni: ide-oda mászkálni, közben pár mondatot, vagy egy két számot beírni, akkor egy ilyen eszköz nélkül meghalnék. Szerintem megspórolom vele a munkaidő harmadát-negyedét.

AL

Pl. olyanról, amelyik úgy implementálta a "cookie-policy" baromságot, ahogy a félkegyelmű EU-nak kellett volna elsősorban.

https://i.imgur.com/U7obZDu.png

Persze nem gond, hogy az EU elkúrta több száz millió ember böngészési élményét a következő 5-10 évre, karöltve a guglival meg az összes többi monitorozó, privacy ellenes multival, nem gond. Sőt, még hasznos is, hiszen megmutatta, hogy mennyire kompetens az EU, ha az uborka görbületének szabályozásánál kicsit összetettebb dologról van szó.

Semennyire.

Ehhez is az Apple kell, hogy megmutassa, hogy hogyan is kellett volna ezt normálisan megoldani... szégyen...

És az is szégyen, hogy az EU képes volt 10+ évnyi best-practice-t szembe köpni és kötelezővé tenni valamit, ami amellett hogy idegesítő, még szar is.

Köszi EU, köszi gúgöl...

https://i.imgur.com/b2yuolA.png

az egér nélküli munkát nekem is régi vágyam megvalósítani, 90%-ban sikerült is de van amit sajnos nem

pl navigálás az editorban, pl a képernyő jobb sarkába a sor közepére, mire billentyűvel odaérek (eclipse) az nagyon fusztráló, egérrel meg odakatt és kész, nálad ez sikerült?

ugyanígy webes fejlesztésnél folyamatosan tesztelem a html oldalt és kattingatnom kell sajnos

Szerintem megspórolom vele a munkaidő harmadát-negyedét.

Ööö... izé... ha neked az egér-billentyűzet váltás, illetve az egér megöli a produktivitást, akkor valamit rosszul csinálsz... vagy te vágod a fát az erdőben minden egyes projektnél.

A legutóbbi Android projektem összesen ~30 órás meló volt, mindennel együtt ~3000 sor és ennek nagyjából a fele IDE által generált forrás, archetype skeleton, effektíve 50 sort írtam óránként... a specifikáció egyeztetésén és a tesztek írásán túl a profiling eredmények alapján a kód optimalizálása és a refactor vitte el a legtöbb időt, ezek pedig erősen gondolkodós részek.

Ez a favágás relatív. Igazából amit leírtál az simán lehet favágás. Mondjuk jól megtanult vim refaktoringban is tud nagyon erős lenni a makrók és egyebek miatt. Meg nagyon nem mindegy mi a produktum ami készül, mennyi a hozzáadott érték. Magas hozzáadott értéknél megint pont előnyös a vim. Spec IDE inkább a konzerv projekteknél hoz előnyt, de akkor ebből a szempontból az a favágás. Szóval ezzel szerintem inkább ne dobálozz, pláne ne ilyen sablonok alapján. 

Ettol fuggetlenul kodolaskor a gondolkodasra forditott idohoz kepest eltorpul a gepelese. Ha az utobbit kioptimalizalod mindenfele trukkokkel, nyersz valamennyit, de nem olyan sokat.

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Feladata válogatja, pl én jellemzően kétféle kódot szoktam kalapálni. Az egyik az rutin feladat, meg kell csinálni, ott én is valami IDE-t használok, megy mellette youtube/twitch/spoty. Azokra nem kell odafigyelnem, mert megy magától, ezek jellemzően példakódok általam jól ismert algoritmusokra. Itt azért használok IDE-t, mert közben tartalmat fogyasztok, akár még a linuxhoz sem ragaszkodom közben. 

Van a másik kör, ahol olyan dolgokat rakok össze, ami még sosem volt, még hasonló sem, nincsenek konzervmegoldások. Itt nagyon jó a vim, mert ad egy "zen" jelleget a dolognak, teljes fókusz. Csak a jegyzeteket és a monitort nézem és közben ezerrel pörög az agyam. Itt az is kizökkenthet egy bonyolultabb gondolatmenetből, ha az egeret kezdem el keresni. Ez persze más editorral is működik, csak nekem korlátozottak az ismereteim és nem tudok olyan szintű editort, ami csak bill-ről vezérelhető (az emcs-ot kivéve, de nekem a vim szimpatikusabb volt, de ez izlések és pofonok). 

Persze az is kérdés, hogy a papiros dolgokat belevesszük-e a folyamatba, vagy csak kifejezetten a kódolás folyamata van. Ha belevesszük, akkor természetesen eltörpül az idő amit az editor előtt töltök. 

Mondjuk jól megtanult vim refaktoringban is tud nagyon erős lenni a makrók és egyebek miatt.

Nem tudta ezt eddig senki bemutatni, hogy jobb lenne, mint mondjuk egy mai IDE refactoring, ahol nem bután átnevez vagy átmozgat, hanem a nyelv szabályai szerint megkeresi, hogy hol van használva, hol van rá hivatkozás kommentben, egyéb fájlokban és átnevezi a változóneveket is, ha változott az osztály neve.

Magas hozzáadott értéknél megint pont előnyös a vim.

Miért is?

Mert ott sokkal jobban kell fókuszálni, igazából itt lehet gondolni minden csak bill-ről vezérelhető editrorra, ami kényelmesen használható. Ilyenkor nálam csak a jegyzetek vannak. Valamint jellemzően itt nincsenek konzerv sorok a programban, szinte minden kézi munka. Az a kevés ami meg ismétlődik, azok meg mehetnek makróról, de én azt nem szoktam, mivel akkor az ki tud zökkenteni a gondolatmenetből. Mondom feladata válogatja. Szerintem nincs olyan, hogy ez a legjobb editor, mint ahogy legjobb programnyelv se. Mondjuk ami a te feladataidra haszons és jó, az lehet másnak más feladatra szenvedés, és amit meg én használok az meg valószinű neked lenne az. Viszont amire használjuk, arra hatékony. 

Arra próbáltam meg rámutatni, nincsen olyan, hogy legjobb, vagy te ha másképp csinálod akkor az favágás. Kb olyan mint az autópályán a gyorshajtás. Mész a külső sávban és levillognak, kihúzódsz és látod hogy a sietős kollegát már villogja le egy nála is gyorsabb. :)

Értem, de továbbra is ott tartunk, hogy a vim refactor lehetőségei szánalmasak és ott, hogy ha jelentős időt spórolsz azzal, hogy egér-billentyű között váltasz, akkor favágó munkád van, ahol nem kell gondolkodni, szalag mellett kell dolgozni ütemre.

Szóval szerinted, csak a refaktoring alatt kell gondolkozni, és ha nem azt csinálod akkor favágó munkát végzel, szallag munkás vagy. 

Egyáltalán nincsen igazad, pl ha az a kód egy teljesen új módszer, mondjuk egy teljesen új nemlineáris szabályozástechnikai módszer szimulációját írod, akkor többet gondolkozol közben, mint amit egy élet alat a kódolással kapcsolatban egy átlag Android dev-nek kell. Ilyenkor egy olyan editor, amiben tudsz fókuszálni és váltogatod át a képleteket kódra, ott az egér tud zavaró lenni és ezért a vim lehet egy nagyon jó választás, és az nem favágó munka hidd el. Azért mert Android dev körökben igaz amit gondolsz nem jelenti azt, hogy máshol is így van és nem kell ilyen korlátozott féligazságokat kinyilatkoztatni. Sok ilyet lehet mondani, példa képpen lehetne említeni, azt a féligazságot, ami szerint ha refaktorálnod kell a kódot, akkor nem tervezted meg jól. Ez is jól hangzik, de ugyanúgy nem igaz, mint ahogy ammit írtál az sem. 

Szóval szerinted, csak a refaktoring alatt kell gondolkozni, és ha nem azt csinálod akkor favágó munkát végzel, szallag munkás vagy. 

Keversz két dolgot.

1, ha fejlesztés közben szignifikánsan számít, hogy a kezed folyamatosan a billentyűzeten van-e, akkor favágó munkád van.

2, a vim refactor tudása manapság már szánalmasan kevés

Ez két külön dolog, egymástól teljesen független.

Egyáltalán nincsen igazad, pl ha az a kód egy teljesen új módszer, mondjuk egy teljesen új nemlineáris szabályozástechnikai módszer szimulációját írod, akkor többet gondolkozol közben, mint amit egy élet alat a kódolással kapcsolatban egy átlag Android dev-nek kell. Ilyenkor egy olyan editor, amiben tudsz fókuszálni és váltogatod át a képleteket kódra, ott az egér tud zavaró lenni és ezért a vim lehet egy nagyon jó választás, és az nem favágó munka hidd el.

Bocsánat, de neked egyszerűen szokásaid vannak, amiken nem tudsz változtatni és ezt próbálod most valahogy racionalizálni.

Azért mert Android dev körökben igaz amit gondolsz nem jelenti azt, hogy máshol is így van és nem kell ilyen korlátozott féligazságokat kinyilatkoztatni.

Nem vagyok Android dev, hanem az is.

Sok ilyet lehet mondani, példa képpen lehetne említeni, azt a féligazságot, ami szerint ha refaktorálnod kell a kódot, akkor nem tervezted meg jól. Ez is jól hangzik, de ugyanúgy nem igaz, mint ahogy ammit írtál az sem. 

Általában azért kell refactor, mert változnak az igények, elég régóta fejlesztek, olyan projekten még nem nem vettem részt, amit használatba vettek és utána ne változtak volna az igények.

Külsőségek alapján ítélsz, ha azért lenne a kezed folyamatosan a bill. felett, mert leütésszámra fizetnek és sok kódsort kell rövid idő alatt írnod, akkor talán lehetne igazad, de akkor sem mindig. A hatékonyságot más oldalról kell megfogni. Viccesen írhatnám, ha nálatok a leütésszám a hatékonyság fokmérője az a biztos jele annak, hogy favágómunkát végzel.  Igazából szerintem az a favágó munka amikor kevés tudás és kreativitás kell valamihez és most csinálod valamiből az n+1-et. Bizonyos esetekben főleg a teljesen új dolgoknál, ami rengeteg tudást és kreativitást igényel ott jellemzően viszonylag kevesebb kódsor van. Ott a kódolás közbeni öszpontosításon van, valamint közben is pörög az agyad ezerrel. Minden ami ebből kizökkent sok esetben azt eredményezi, hogy megakad a gondolkozásod és van, hogy újra kell kezdened az adott gondolatmenetet. Ha ezeket a hatásokat nem tapasztalta és csak szokásnak írod le, akkor nem nagyon volt még részed ilyesmiben. 

Tudom mi a refactoring, azt a példát azért írtam mert féligazságokból kiindúlva egy jól hangzó bullshit, azt állítottam, hogy a tiéd is ilyen. Látom sikerült felfedezned, hogy az bullshit, csak az a mondatrész, amiben leírom, hogy nem igaz az már nem jutott el a tudatodig, pedig már az elején utaltam rá, hogy ilyesmi következik. 

Minden ami ebből kizökkent sok esetben azt eredményezi, hogy megakad a gondolkozásod és van, hogy újra kell kezdened az adott gondolatmenetet.

Azt akarod nekem bemesélni, hogy egy fejlesztőt kizökkenti a munkából, ha nem vim van előtte és hozzá kell érnie egy egérhez néha?

Szerintem ezt nem egyhamar fogod megérteni. Amikor az adott sor implementálásához évek matek tanulása kell, hogy meg tudd fogalmazni, akkor minden apróság ki tud zökkenteni, nem csak az egér, hanem zene, meg akármi. Nem baj, hogy ilyet még nem csináltál, én olyan n+1-edik dolgot nem tudnék csinálni. Vannak olyanok akiknek kell az érdekes, bonyolúlt feladat. Nem vagyunk egyformák. Csak favágó melónak ne nevezz olyat amiről fogalmad sincsen. 

Ha ennyire nem akarod mozgatni a kezedet, csinalj sajat billentyuzetet! Nem akkora urtechnika, van tobb nyilt forrasu firmware is. Ha nem kell bonyolult funkcio, az Arduinos keyboard libbel is megoldhato (egyik ismerosommel csinaltunk celfotos programhoz ilyet, mert nagyon hulye hotkey-ei vannak, igy meg 1-1 gombnyomas).

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Amikor az adott sor implementálásához évek matek tanulása kell, hogy meg tudd fogalmazni, akkor minden apróság ki tud zökkenteni, nem csak az egér, hanem zene, meg akármi.

Oké, figyelemzavaros vagy, minden apróság elviszi a figyelmed, van ilyen... csak ne a szükséges eszközzel, a fejlesztés hatékonyságával meg az egér-billentyűzet váltás idejével akard ezt racionalizálni.

Csak favágó melónak ne nevezz olyat amiről fogalmad sincsen.

Márpedig innen nézve veled csináltatják a favágó melót, amíg a többiek lenn a büfében megtervezik a következő pár hónap irányvonalait.

Nem arról van szó, hogy csak a vim. a többi nem tud semmit. Nagyon jó IDE-k vannak, feladata válogatja, hogy mit érdemes használni. Mint ahogy programozási nyelvekkel is. Nem tudod azt mondani, hogy csak az a programnyelv a jó. Van amire mondjuk a C a jó, van amire Python...stb. Mondjuk ha valaki oktató anyagot csinál, akkor ezek a notebook jellegű IDE-k tök jók lehetnek, mert nagyon jó magyarázó szövegeket tudsz a kódba berakni, ott kevésbé mutatna az ember mondjuk vim-et, de ott is vannak esetek amimkor inkább azt. Nem végletekben kell gondolkozni. Mindennek megvan a létjogosultsága. Pl MIT-n van egy kurzus, ami pont arról szól, hogyan lehet hatékonyan fejleszteni, ahol mutogatnak shell programozást, vim-et, git-et...stb. A vim ereje a fejleszthetőségében van, nagyon jó toolok vannak hozzá. Van a vanilla vim, az is jó, de pl nvim követi ugyan a vim-et, de van benne pár dolog ami miatt sokkal többminden érhető el alatt. Szóval ha valaki használja akkor nem az van, hogy feltette csomagból és használja, hanem rendesen testre kell szabni. Ez sokaknak hátrány, viszont sok esetben tud előny is lenni. 

Csak a tisztánlátás érdekében. A (n)vim egy szövegszerkesztő, amit eléggé át lehet alakítani, elég sok programmal össze lehet kötni. Több száz program- és leíró nyelv szintaxisát ismeri, illetve mi is bővíthetjük igényeink szerint.

Egy refatoring-tool lényegében tartalmazza az adott nyelv értelmezőjét, mert csak így tudja eldönteni, hogy az adott részben például melyek a szabad és kötött változók, eljárássá/függvénnyé kiemeléskor milyen paramétereket kell használni. Vagy adott változó/eljárás átnevezésekor az mely más fájlokban is szerepel, illetve hol vannak ugyanolyan nevű, de az átnevezni kívánttól független előfordulások. Ezt az adott nyelv ismerete nélkül nem lehet megtenni. Egyrészt nem nagyon van őrült, aki ezt az elemzőt VimScript-ben leprogramozná több tucat nyelvre. Másrészt a Unix valaha az egy-egy feladatot megoldani képes, de egymással összekapcsolható programokról volt híres. Éppen ezért fordultak az nvim hívei a https://microsoft.github.io/language-server-protocol/ irányába: https://neovim.io/doc/user/lsp.html

Ezzel leosztották a feladatot másra, de még mindig elég rugalmasan illeszthető a végeredmény a szövegszerkesztőhöz.

Persze aki 8 órában refaktorál, annak nem érdemes beleugrani a vim megtanulásába. Nem érdemes senkit a vim használatára rákényszeríteni. (Bár megpróbálkoztak vele az informatikus hallgatóknál, mert a vim valamilyen verziója biztos elérhető bármely Unix-os/Linux-os gépen, és ha még a terminálelállítások el is vannak cseszve, a régi nyomtató-billentyűzet fajta terminál stílusában még mindig lehet szöveget szerkeszteni.) Tudjuk sokan elvannak az mcedit-tel vagy a nano-val, ha konzolon kell dolgozniuk. Egészségükre! Persze ott van a másik véglet a MacBook-on használt (Mac)vim, és ezzel adnak elő konferencián is. Lehet azt mondani rá, hogy sznobizmus, vagy divat. (Talán nem is áll messze az igazságtól, de ne általánosítsunk!)

Nekem kb. 30 évem van a vim-ben, és van egy jól belőtt konfigurációs fájlom. Ha egy új gépre kell költözni, ott valamit csinálni, a fájl átmásolása után már otthon érzem magam, minden az ami az ujjaimba rögzült, azonnal megtalálható. (A program által nyújtott lehetőségek legalább felét nem használom, saját VimScript fájlt sem íram, nekem elegendőek a makrók.) A kezdők szeretnek összeszedni százával plugin-okat. Egy fentebbi kérdésre lehetne a válasz, hogy https://code.tutsplus.com/tutorials/vim-essential-plugin-easymotion--ne… de számomra elég csak tudni, hogy melyik sorra kell menni (alapbeállítás a relatív sorszámozás nálam), és ott hova kellene pozicionálni. Nagyjából 6-7 gombnyomás, de gyakran még annyi sem. Persze majd száz "short-cut" közül kell tudni választani. Van egy jó könyv, mely a címében is utal rá, hogy milyen gyorsan lehet szöveget szerkeszteni ezzel a programmal: Practical Vim: Edit Text at the Speed of Thought

Miután mindent IS be lehet állítani, ugyanaz a program lehet egy distraction-free environment, ahol csak a levél/regény szövege látszik, de egy programozási környezet, ahol egy gombnyomásra van a kurzor alatti kulcsszó helpje, vagy egy gombnyomásra át lehet dobni az aktuális sort/függvényt a REPL számára, hogy az ott lefusson; gépelés során jönnek a javaslatok az objektum metódusairól, a szintaktikai vagy formázási hibákról. Mazochisták debuggert futtatnak benne, vagy helyi gépen távoli gépek fájljait szerkesztik. Lehet szeretni, de gyűlölni is; valamint milliomodjára rákeresni, hogy hogyan is lehet belőle kilépni.

AL

Szerkesztve: 2020. 12. 24., cs – 18:21

Nekem egy Microsoft Sculpt Comfort Mouse-om van, a plusz gombokat az asztalváltás funkciókra állítottam be (áttekintő nézet, előző/következő asztal), vagyis nem mondanám fejlesztő specifikusnak. Az utóbbi fél évben macOS-en dolgoztam, sajnos arra nincs hivatalos szoftver* így azon nem tudom ezeket a gombokat kihasználni.

* 3rd party van de azt nem próbáltam, illetve most rákeresve lehet, hogy nem is kell plusz szoftver hozzá

nekem mindenfele sokgombos logitech egereim voltak, de macos-en szivas volt mindegyik. neha kiadott a logitech ra drivert ami altalaban instabil volt, sleep utan hol mukodott hol nem, neha crashelt is, stb, szoval megutaltam egy eletre.  probaltam keresni direkt mac-hez gyartott sokgombos egeret de nem talaltam, ott inkabb az 1 gombos eger a divat :)

vegul vettem egy magic touchpad vagy mit, na az nagyon bejott. nem is akarok mar egereszni.

ott inkabb az 1 gombos eger a divat :)
 

Nem gond, hogy a '90-es években ragadtál, de legalább ne hangoztasd.

vegul vettem egy magic touchpad vagy mit, na az nagyon bejott. nem is akarok mar egereszni.

Na látod. A XXI. század szele elért téged is.

MX 3 master ——> Profilozhato alkalmazas szerint.

Nagyjából 2010-2013 között hobbi szinten 3D modelleztem 3ds Max-ben. Mikor már csináltam pár egyszerű modellt, vettem egy ilyen egeret: https://ek.ua/A4-TECH-F6.htm
Ennek az oldalsó gombja igazából 5 gomb. A nagy gombra beraktam a "pan"-t, felém esőre a "zoom"-ot, vele átellenben meg a "orbit"-ot. Valami volt még a másik kettőn is hirtelen nem ugrik be. A lényeg, hogy ezekkel baromi egyszerűen és kényelmesen tudtam navigálni a 3D térben, nagyon gyorsan el tudtam csípni bármelyik edget vagy vertexet bárhol egy többszázezer polygonos modellen is. Ilyesmihez nagyon jók viszont azóta sem tudtam semmi olyat rakni ezekre a gombokra amiknek hasznát venném programozásnál, webezésnél. 

3D modellezés miatt az oldalsó föl-le gombok a ctrl-z és ctrl-y-ra vannak mappelve. Igazából script irogatás közben is jól jön a visszavonás.

Steelseries Rival 500 nagyon jó. Bár nem fejlesztésre használom, de könnyebb vele az élet.

No God, no peace. Know God, know peace!

mx master, a elore/hatra nyilgombok copy ill paste aparncsokra van mappelve, tudom, hogy a ctrl+c se sok ido, de hidd el sokkal gyorsabb es intutivabb (legalabbis nekem)

Én karácsonyra vettem egy Rapoo mt750s-t, ami elvileg a sokak által emlegetett Logitech MX Master 3 klónja. Mivel az eddigi egereim nagyjából 2 ezer forintba kerültek, sajnáltam volna 35-öt adni a Logitech-ért, a Rapoo meg csak 16 volt.

Van rajta előre/hátra gomb, ezeket nagyon szeretem, viszont az oldalra görgő nem sok helyen működik. Ti ezt hol használjátok?

Negyven napig megy elvileg egy feltöltéssel amúgy, és USB-n töltöd, de sajnos töltés alatt nem lehet használni.