Przejdź do głównej zawartości

Edytor

Edytor kodu to najważniejsze narzędzie programisty, a przy tym najbardziej naznaczone indywidualizmem, to co wygodne dla jednego, nie będzie wygodne dla drugiego (ktoś pamięta świętą wojnę Vima z Emacsem?). Przez 20 lat w zawodzie zdarzyło mi się używać wielu różnych, ale dopiero od 10 lat mogę to określić "karuzelą edytorów". Pierwsze 10 lat spędziłem programując w różnych IDE przypisanych do określonych środowisk (Delphi, Java).

Najpierw był Vim, wraz z obudową o nazwie PIDA. Przede wszystkim dlatego, że był to Vim. PIDA przestała być rozwijana wiele lat temu, ale ma następcę w postaci A8.

Potem zacząłem robić na Macu, więc TextMate, a po przesiadce na nowszą maszynkę SublimeText. Te 2 edytory wyznaczyły w swoim czasie standard co edytor dla programisty ma mieć. Najdłużej używałem SublimeText - również na linuksie. Na linuksie również miał wszystko, może poza stabilnością. Miał również denerwujący screen przypominający o tym, żeby kupić wersję płatną i bardzo, bardzo mi to nie pasowało.

A potem rewolucja, Visual Studio Code od Microsoftu. Platforma na której go zrobiono przypomina Atom, którego od czasu do czasu używam pomimo jego humorów, bo jeszcze nie ma integracji PlatformIO z VSC - ale to pewnie do czasu. VSC stało się najważniejszym moim edytorem do kodu - nie tylko w Pythonie. Co również polecam wszystkim pozostałym, jednocześnie przypominając, że pomimo że to najważniejsze narzędzie, to jest to tylko edytor. Naj-naj-najważniejszy jest zawsze kod.

Komentarze

  1. To brzmi podobnie do tego, co widzę na swoim podwórku. Ludzie używają IDE jeśli potrzebują bardzo konkretnych narzędzi/wsparcia dla pewnych frameworków, a jeśli nie jesteś skazany na IDE to w ruch idzie Sublime, Atom, no i oczywiście VSC.

    Mój główny edytor w tej chwili to Atom/VSC, w zależności od potrzeb. W korpo-pracy nadal potrzebne jest mi IDE, bo projekty których doglądam są pisane pod JVM (a korpo kupuje licencje na IntelliJ), choć np. do dłubania w Clojure dobrze zapowiada mi się Atom.

    Moim pierwszym "programistycznym" edytorem był CED na Amidze. A z mniej egzotycznych, na platformie x86, edytor wbudowany w Dos Navigatora. Skromnie obdarzone "ficzersami", ale dawały radę.

    OdpowiedzUsuń
  2. Używałem VSC, ale wróciłem do ST3. Lubię się skupić na kodzie.

    OdpowiedzUsuń
    Odpowiedzi
    1. Jak dla mnie wygoda zbliżona, a wielki minus ST - nie obsługuje ligatur programistycznych (Fira Code FTW!).

      Usuń

Prześlij komentarz

Popularne posty z tego bloga

Programowanie ESP8266 w C/C++

ESP8266 powoli ustępuje miejsca swojemu następcy ESP32, ale jest to proces wyjątkowo powolny. Może to ceny tak samych chipów jak i płytek developerskich to powodują (niewiele jest gotowych modułów w cenie poniżej $10 z przesyłką), a może rozbudowany ekosystem bibliotek do ESP8266. W każdym razie ze starszym bratem ESP32 jeszcze długo będziemy mieć do czynienia, zwłaszcza że jest to wciąż jedna z najlepszych opcji jeżeli chodzi o mikrokontrolery.

ESP8266 można programować w Lua lub w Pythonie, jednak najlepszym wyjściem jest zaprogramowanie własnego firmware w C++ lub w C - daje to największą kontrolę i zapewnia najlepszą wydajność. Jakie mamy do tego możliwości? Od najłatwiejszej do najbardziej skomplikowanej.
ESP8266 core dla Arduino Link: Github

To jest najprostsze rozwiązanie, implementacja ramówki Wiring dla ESP8266. Jakkolwiek można tę obsługę zainstalować w Arduino IDE, to nie ma to większego sensu, bo nie da się tego edytora używać do niczego poważniejszego. Pisze się to w nor…

RetroPie, bo mi się dziecko alienowało

Dziecko moje najdroższe alienowało mi się siedząc przed komputerem w swoim pokoju. Nie żebym jej zabraniał, ale skoro ma grać, to niech gra przy nas, w salonie. Przynajmniej będziemy wiedzieli w co gra.

Wymagane hardware:

Raspberry Pi 2 Mod. B,karta SD min. 8GB,gamepad na USB,telewizor
Opcjonalne w zależności od konfiguracji:

karta WiFi na USBklawiatura na USBpendrive czy inny storage na USB Jak już to wszystko mamy, to możemy robić. Zajmie to parę godzin wszystkiego.
RetroPie Obraz RetroPie pobieramy ze strony projektu, to będzie ten którego nazwa kończy się na rpi2.img.gz. Następnie obraz ten trzeba rozpakować i nagrać w standardowy sposób na kartę SD. Wkładamy kartę do RPi, podłączamy pada do USB, bootujemy naszą zabawkę i zaczynamy konfigurowanko jak zwykle z RPi (z podłączonego klawikordu i na telewizorze, albo po ludzku, po zalogowaniu przez SSH), czyli najpierw używając skryptu raspi-config rozciągamy system plików na całą kartę, reboot, pełna aktualizacja systemu, być może reboo…

RetroPie, ROM-y z USB

Po wrzuceniu kilku ROM-ów na PSX okazało się, że karta SD z której bootuje się system jest za mała na to, żeby je tam trzymać. Inne opcje jakie przyszły mi do głowy to trzymać je na pendrive albo zamontować katalog z NAS po Sambie. W pomieszczeniu gdzie stoi telewizor WiFi działa co najwyżej jako-tako (nikt nie pomyślał o kablaturze podczas budowy...), więc na początek pójdzie 8GB pendrive. Powinno wystarczyć na parę dni.
Albo rybka, albo pipka RetroPie ma bardzo fajny ficzer automatycznego transferu ROM-ów po podłączeniu storage do USB. Jakkolwiek bardzo miłe i user friendly, to zupełnie nie będzie przydatne w momencie, gdy będziemy tam trzymać ROM-y. W końcu jak będziemy chcieli sobie coś tam wgrać, to i tak trzeba będzie wyjąć pendrive i włożyć go ponownie. Zaczynamy więc od wyłączenia tego wodotrysku, odpalamy retropie_setup.sh i na ekranie głównym wybieramy "Setup / configuration", a następnie "USB ROM Service":
i dalej "Disable USB ROM Service": Wyd…