Zastanawiam się nad stworzeniem nowego układu klawiatury do programowania. Teraz głównie programuję w HTML, JavaScript / jQuery / CoffeeScript, CSS / LESS / SASS, chociaż wkrótce będę mógł zająć się skryptami powłoki i RegEx, z być może LUA, C ++ i Java za kilka lat. Chcę mieć dowody naukowe na temat lokalizacji klucza. Mam pomysły / wymagania, niektóre same wymyśliłem, niektóre zaczerpnąłem z innych:
- Prawie wszystkie klucze można zmienić
- POWRÓT , Lewy SHIFT , Lewy CONTROL , SPACJA i TAB muszą pozostać, ale wszystkie inne, w tym cyfry, symbole i klawisze ruchu są otwarte na ruch
- Może być optymalna opuścić zxcv & perhhaps s zatrzymać się w miejscu, z powodu wspólnych Undo / wytnij / kopiuj / wklej / Save nawyków :)
- Klawisz DELETE prawdopodobnie zostanie przeniesiony tam, gdzie jest CAPS LOCK :)
- Jest mało prawdopodobne, aby pasujące do siebie nawiasy jak () {} [] <> znajdowały się obok siebie; patrz poniżej
- Jedynym dokładnym sposobem IMHO zliczania użycia klucza jest rejestrowanie kluczy, a nie liczba plików:
- Znaczna część „programowania” to wysyłanie e-maili, wysyłanie postów na fora, Twitter, zgłaszanie błędów, surfowanie po Internecie itp.
- Uważam, że większość użycia klawiatury to „ruch”; tabulacja między polami, strona w dół, przenoszenie kursorów itp. Nie są one przechwytywane przez pliki wyjściowe
- Wielu redaktorów korzysta z autouzupełniania i makr, więc ograniczniki:)}]> mogą nie być tak często wpisywane jak programy otwierające, dlatego dokładne rejestrowanie tylko kluczy i nie parsowanie plików będzie dokładne.
Więc moje pytania:
- Jakie są bezpieczne keyloggery z bezpłatnym oprogramowaniem typu open source, które nie będą przesyłać plików, chyba że sam wyślesz osobny plik? Wolałbym NIE zbierać nazw logowania i haseł, nie tylko ze względów bezpieczeństwa, ale także dlatego, że może to rzucić moją analizę IMHO.
- Jakie programy mogą być używane po stronie klienta do analizy liczby pojedynczych i par kluczy? Lub jak najlepiej zbudować?
- Gdzie najlepiej znaleźć ochotników do pomocy?
Najlepsze dotychczasowe badania: http://www.michaelcapewell.com/projects/keyboard/layout_capewell.htm
http://viralintrospection.wordpress.com/category/technology/keyboard-layouts/
& Wikipedia: Keyboard_layout # Non-QWERTY_keyboards_for_Latin_scripts
TIA!
keyboard
keyboard-layout
ergonomics
keylogger
tomByrer
źródło
źródło
<>{}[](i inne klucze, które obecnie wymagają shift) własne klucze - tak naprawdę nie uważałbym się za programistę, ale wiem, że to najbardziej denerwuje podczas pisania skryptów bash.Odpowiedzi:
Użyj programu takiego jak WhatPulse, aby zarejestrować, które klawisze zostały uderzone i ile razy.
Po zapytaniu w sieci IRC FreeNode o tym, jak zebrać kluczowe częstotliwości, użytkownik zaprowadził mnie do tego:
count_digraphs()i naciśnij Enter.Wyniki są odczytywane w następujący sposób:
"ar" 7 17 10 "ra"co oznacza, że „ar” został wciśnięty 7 razy, „ra” został wciśnięty 10 razy, a wszystkie razem „ar” i „ra” zostały wciśnięte 17 razy razemźródło
Klawisze przemieszczania w edytorach są najczęściej przystosowane do optymalnego wykorzystania QWERTY, więc z pewnością będą musiały zostać ponownie przypisane, jeśli zmienisz układ klawiszy i chcesz optymalnego rozmieszczenia wszystkiego, do czego dążysz. Np. W Vimie przyciski HJKL są używane z jakiegoś powodu w QWERTY i najprawdopodobniej będą musiały zostać ponownie przypisane z powrotem do tego samego miejsca po zmodyfikowaniu mapy kluczy.
Chodzi mi o to, że nie pomoże ci to w znacznym stopniu śledzić ruchy i edytować klucze i używać go jako podstawy nowego układu, ponieważ można je łatwo zmienić (w każdym edytorze jest to warte soli, a ponieważ mówimy o programistach układ, najprawdopodobniej mówimy o Vimie lub Emacsie), nie powinien przeszkadzać w rozmieszczeniu literalnych klawiszy i został już zoptymalizowany (ponownie: nie mówimy o Notatniku).
Próbujesz rozwiązać problem, który jest nieefektywnym sposobem na wydajność , szczególnie dla programisty ** imho **. Byłoby o wiele większy efekt, gdyby po prostu dowiedzieć się więcej o narzędziach (jeszcze raz: prawdopodobnie Vim / Emacs). Przekonasz się, że coraz mniej czasu spędza się na pisaniu znaków podczas programowania, a więcej (ale bardziej wydajnie) spędza się na automatycznym uzupełnianiu, automatycznym tagowaniu, automatycznym wcinianiu, szybkim wyszukiwaniu definicji funkcji itp. Klawisze aby to wszystko zrobić, są już przystosowane do zapewnienia wydajności, a duże przyspieszenie prędkości jest po prostu znane. Dlatego twierdzę, że inny układ klawiatury jest odpowiedni, jeśli chodzi o porównywalnie niszczącą wydajność , ponieważ jest już ich wielelata ćwiczeń QWERTY. Gdyby QWERTY spędził taki sam czas szkolenia analitycznego, jak osoby, które zmieniają układy, spędzają na Dvoraku, zauważą również przyspieszenie. Prędkość pochodzi z wyraźnym treningiem.
Jeśli byłeś copywriter / tłumacz / autor / itp., Ktoś, kto faktycznie spędza czas na pracy z dosłownym znaczeniem klawiszy, to inny układ może być pomocny. Dla programisty najlepszą wskazówką jest zazwyczaj uzyskanie przynajmniej angielskiego układu klawiatury, ponieważ idiomy programowania zostały przez nie ukształtowane i ich rozmieszczenie klawiszy (w moim lokalnym układzie klawiszy
@$[]{}~wszystkie są za AltGr, co jest dość nieoptymalne).tldr: Dvorak / Colemak / [kolejna „najlepsza rzecz od krojonego chleba”] (prawdopodobnie) rozwiązuje problem tylko dla tych, którzy wprowadzają dużo płynnego tekstu w określonym języku (najczęściej angielskim). Do programowania potrzebne klucze nie podlegały tym samym ograniczeniom co język dosłowny, a zatem zostały już zoptymalizowane pod kątem swojego celu (który nie polega tylko na „pisaniu tak szybko, jak to możliwe”, ale opiera się bardziej na operacjach logicznych. Zobacz Wigor). Wierzę, że czas poświęcony na naukę alternatywnych układów i zamieszanie, które z pewnością zdarza się raz za razem, zdecydowanie nie jest warte wysiłku w większości przypadków (nie tylko własne zamieszanie; inni, którzy siadają na tym samym terminalu, którego ostatnio używałeś, rzucą rzeczy na ciebie), w tym programisty.
źródło