Andrew Brookins
On december 23, 2021 by admin2017-ben feltettem a kérdést: “Lehet-e kódot írni iPad-en?”. 2019-ben a válasz alapvetően ugyanaz: nem igazán. De a dolgok egyre érdekesebbé válnak.
Forrás: ha iPad-en kódolsz, nézd meg, hogyan lehet az iOS vágólapját SSH-n keresztül szinkronizálni egy távoli géppel. Egy nemrég megjelent bejegyzésben azt is megvizsgáltam, hogyan használhatunk böngészőfejlesztő eszközöket iPadOS-en az Inspect alkalmazás segítségével.
“Programozás” iOS-en: a Shortcuts alkalmazás
Az iPad még mindig nem képes natív programozásra. Vagyis nem találsz egy titkos ajtót, amely egy UNIX shellhez vezet, ahová homebrew-t és C fordítót telepíthetsz. Bárcsak!
A Swift Playgrounds-t nyugodtan figyelmen kívül hagyhatod, hacsak nem az a célod, hogy megtanuld a Swiftet. A Playgrounds nem egy általános célú programozási környezet; a kódolni tanuló gyerekeknek szól.
A programozhatósághoz legközelebb álló, az iOS natív funkciójaként létező programozási lehetőség a Shortcuts alkalmazás, amely kisebb feladatok automatizálására és alkalmazások összekapcsolására alkalmas.
Ez a Workflow, egy népszerű alkalmazás átnevezett Apple-verziója, amely nagyjából ugyanezt tette. A Shortcuts segítségével összefűzhetsz egy sor olyan műveletet, amelyet általában elvégezhetsz, például bekapcsolhatod a Ne zavarjon, lejátszhatsz egy adott albumot (én a Brute Force-ot ajánlom a The Algorithm-tól), és megnyithatsz egy SSH-kliens alkalmazást vagy egy szövegszerkesztőt.
A Shortcuts valószínűleg hasznos valakinek, de én nem használom sokat, és túl korlátozott ahhoz, hogy programozásnak nevezzem!
Editing in Native iOS Text Editors
Még nincs minden teljesen elveszve. Először is, ha elismered, hogy az iPad Pro egy potenciális vékony kliens, amely egy szerverrel párosul, akkor vannak lehetőségeid. Vannak nagyszerű SSH alkalmazások, mint például a Blink. De nem feltétlenül kell közvetlenül a szerverhez csatlakozni mindenhez. Ha inkább natívan szerkesztenél az iPaden, és felépítenél egy csigarendszert, amely felemeli a kódodat egy felhőszerverre, esetleg egy olyan folyamatos integrációs rendszerrel, mint a GitLab, az is lehetséges. Mindkét lehetőséget megvizsgáljuk.
Hé, írtam egy könyvet!
A Django adatbázis-teljesítményének temploma az új könyvem, amely a táblás játékot, az adatbázisokat és a Djangót vegyíti. Fedezz fel egy romos templomot, miközben fejlett Django adatbázis-teljesítmény trükköket tanulsz!
Valószínűleg nem futtathatod a kódodat iOS-en, hacsak nem Python
Van némi mozgástér a kódod közvetlen futtatása körül az iPad-en, ha Python fejlesztő vagy. A Pythonista alkalmazás idővel egy iOS-automatizálásra összpontosító Python-szövegszerkesztőből egy hackelhető Python-fejlesztői környezetté nőtte ki magát, amely olyan nagy csomagokkal szállítja a programot, mint a NumPy, van egy Pythonban implementált bash-szerű héja, és támogatja a bővítményeket.
A Pythonon kívül nem találtam semmilyen általánosan hasznos értelmező vagy fordító alkalmazást iOS-en.
Forrás: Olvasók figyelmembe ajánlották a Continuous, egy C# és F# IDE-t iOS-re, valamint a Rescript, egy JavaScript/node.js IDE-t iOS-re. Mindkettő ígéretesnek tűnik, és lehet, hogy egyenértékű a Pythonistával, de még nem használtam őket. Van még a Replete, egy iOS-alkalmazás, amely egy ClojureScript REPL-t (read-eval-print loop) ad; bár szórakoztató, kevésbé tűnik funkciógazdagnak, mint a többiek.
A natív iOS-szerkesztők egyre jobbak
Egyre több tisztességes szövegszerkesztő van, amely az értelmező vagy fordító komponens nélkül fut. Az olyan alkalmazások, mint a GoCoEdit és a Textastic olyan szerkesztési élményt nyújtanak, amelyek kezdenek elnyerni az asztali szerkesztők néhány, az alapokon túlmutató funkcióját – például a fájlok homályos keresését.
Ezek a szerkesztők kezdenek együttműködni egymással és a Working Copy nevű nagy teljesítményű Git alkalmazással, valamint az Apple által biztosított Files alkalmazással, hogy érdekes hatásokat érjenek el. A Working Copy képes lekérdezni egy Git-tárat, és elérhetővé tenni azt szerkesztésre az olyan alkalmazások számára, mint a GoCoEdit; a szerkesztőben végzett változtatások automatikusan visszatükröződnek a Working Copyben, ahol aztán le lehet rögzíteni őket.
Az iOS-szövegszerkesztőkből hiányzó funkciók
Ezek közül a szerkesztők közül azonban egyik sem nyújt önmagában olyan élményt, amely tényleges szoftverfejlesztésre alkalmas. A Dreamweaverről beszélünk, nem az Emacsról.
Egy hiányzó darab jelenleg a projektkeresés; azaz adott egy könyvtár vagy könyvtárak halmaza, lehetővé teszi a felhasználó számára, hogy a benne lévő összes fájlban keressen szöveget. Ha GoCoEdit-et vagy iVim-et használsz, akkor ennek a közelítését úgy érheted el, hogy a Working Copy nagyszerű keresőeszközével, ami valóban rendelkezik ezzel a funkcióval, megkeresed a fájlokat, majd a megosztás menüből kiválasztod pl. a “open in GoCoEdit” opciót. A Textastic valamiért nem kínálja ezt a funkciót. Akárhogy is, ez működőképes egy kis szűkösségben, de valószínűleg nem fogja elérni a keresett “flow”-t.
Side note on iVim: it’s gotten getting better. Lehet .vimrc
fájlod és pluginokat tölthetsz le az alkalmazás fájlrendszerébe. Állítólag a pluginek működnek, amíg Vimscriptben vannak megírva. Azt is vegye figyelembe, hogy ez a Vim 7, tehát nincs async.
Az iOS-szövegszerkesztőből dolgozva ne számítson a webes alkalmazásfejlesztés tipikus mintájára. Hacsak nem használsz Pythonistát, nincs szerver, amely a kódodat futtatja az iPaden, így szükséged lesz valamilyen ragasztóra, hogy a szerkesztett fájlodat olyan helyre továbbítsd, ahol valóban fut a kód, például egy szerverre vagy egy szerver nélküli platformra. Számos módja van ennek 2019-ben, valószínűleg a Pythonista, a Zapier, az IFTTT és/vagy a Shortcuts Siri hangparancsának némi használatával. Ha az iPad-en való kódolás az új hobbija, akkor az összes legrosszabb figyelemhiányos szokásának hódolhat a téma felfedezésével.
Ezek a szerkesztők egyike sem kínál lintert vagy kódformázót. Az iOS felépítése azt sugallja, hogy a szerkesztőalkalmazáson kívüli linterek és formázók működésre bírása valószínűleg egy külön alkalmazást igényelne, amely támogatná a lintinget és az üzenetek formázását szöveggel, mint bemeneti információval. Ellenkező esetben a szerkesztőnek kell biztosítania a bináris formátumot, pl. gofmt
. Az értelmezett nyelveken írt eszközök esetében feltételezem, hogy a szerkesztőnek a teljes programozási nyelvet vagy bármit is csinál a Pythonista, a szerkesztőnek kellene csomagolnia.
Az iOS üzenetátviteli jellege elég király
Mennél többet használod az iOS-t bármire, ami nem triviális, annál jobban kezded érezni az üzenetátviteli jellegét. Ahelyett, hogy az alkalmazások egymással és az operációs rendszerrel fájlokon és rendszerhívásokon keresztül lépnének kapcsolatba, minden alkalmazás üzeneteket küld és fogad egymás és az operációs rendszer között.
Ezért a fájlokat a Fájlok alkalmazásban találod, de ez nem csak egy fájlokat tartalmazó könyvtár. Ez inkább egy olyan hely, ahol üzeneteket küldhetsz és fogadhatsz a fájlokkal kapcsolatban az iPad összes alkalmazásában, beleértve az iCloud Drive-ot is.
Azok az alkalmazások, amelyek bármit is csinálnak fájlokkal, fejlettebb funkciókat adtak hozzá, hogy kihasználják ezeket az új, fájlokkal kapcsolatos üzeneteket, amelyeket más alkalmazások támogatnak, így sok szövegszerkesztő alkalmazás már olyan dolgokra is képes, mint egy másik alkalmazás által kitett fájlkönyvtár megnyitása (2019-ben ez “fejlett” az iOS számára). Az így megnyitott könyvtárak általában valami olyasmiben maradnak, mint egy oldalsáv az alkalmazásban, és továbbra is elérhetőek, mintha az alkalmazásban lennének lokálisan.
Egy idő után ez kezd elég menőnek és természetesnek tűnni; egy asztali számítógéphez visszatérve talán egy következetes “megosztás” gombot várna, ami nem létezik. Bárcsak lenne egy professzionális szintű szövegszerkesztő az iOS-en – és fordítók, értelmezők, webkiszolgálók stb.
Iratkozzon fel a hírlevelemre.
Egyszer-egyszer e-mailt fog kapni, amikor elég izgatott vagyok egy technológia miatt ahhoz, hogy írjak róla.
Kapcsolódás egy valódi számítógéphez SSH-val
Ha Blink vagy más SSH-alkalmazás segítségével csatlakozol egy olyan szerverhez, amely képes tetszőleges kódot végrehajtani, és onnan Vimet vagy Emacset futtatni, akkor a dinamikus nyelveken írt webes alkalmazásoknál jellemző minta, miszerint szerkesztesz egy fájlt, megvárod, hogy az alkalmazás szervere újratöltse a szerkesztett fájlt, majd frissítesz egy weboldalt, még működhet.
Az iOS-en persze egy böngészőt fogsz frissíteni. Az iCab-ot javaslom a széleskörű testreszabási lehetőségei miatt, beleértve az általam iOS-en látott legjobb módosítható billentyűparancsokat is.
Hol futtassa a szerverét 2019-ben?
Azoknak, akiknek szükségük van egy távoli szerver és egy olyan valódi szerkesztő erejére és rugalmasságára, mint a Vim, még több lehetőség van, mint korábban volt.
A Digital Ocean remek választás a gyors kezdéshez. A weboldalnak remek UI/UX-ja van, és a támogatást is tartalmazza.
Mindeközben a Google elkötelezettsége a 100%-ban megújuló energia használata mellett vonzó választássá teszi a Google Cloud Platformot, ha nincs szüksége támogatásra, és szeretne egy kicsit több energiát költeni. A GCP “mindig ingyenes” szintje tartalmaz egy f1-micro példányt, amely az Ön igényeitől függően működhet fejlesztési VM-ként.
Az is jól működik, ha egy régi Mac-et állít be szerverként, mert akkor az iCloud Drive segítségével szinkronizálhatja a fájlokat a szerver és az iPadje között, vagy osascript
segítségével küldhet magának szöveges üzeneteket, amelyek mélyen kapcsolódnak az iOS-alkalmazásokhoz. Ezen a ponton a világ a tiéd. Az Apple felélesztette a Mac Minit, így ez egy életképes otthoni szerver/asztaliszámítógép páros az iPadhez.
A fejlesztői webkiszolgáló elérése iOS böngészőből
Pár évvel ezelőtt év, ha egy webes alkalmazást fejlesztettél egy távoli szerveren, lehet, hogy az alkalmazás fejlesztői szerverét egy nyilvánosan elérhető porton kellett futtatnod. Most van egy alkalmazás az SSH tunnelinghez, az úgynevezett – várj csak! – SSH Tunnel.
Az alkalmazásszerver (pl. a Django fejlesztői szervere) eléréséhez először az SSH Tunnel segítségével létrehozol egy alagutat a szerverhez (a számítógéphez), amelyen az alkalmazásszerver fut. A szerveren a /etc/hosts
-ban a “localhost”-tól eltérő hostnevet kell definiálnod, amely a 127.0.0.1-re mutat. Ezután kövesse az SSH Tunnel weboldalán található utasításokat a megfelelő proxy-beállítások beállításához az Ön által használt iOS hálózati kapcsolaton.
A véráldozat elvégzése után beírhatja a megadott hostnevet, pl. old-faithful
és a portot, amelyen az alkalmazáskiszolgálója fut, a választott iOS-böngészőjébe, pl. http://old-faithful:4000
, hogy betöltse az alkalmazást.
Browser Dev Tools, Where Art Thou?
Ha a webes alkalmazás hibakeresésére van szükség, mostantól létezik egy Inspect nevű dev tools alkalmazás. Egész jól működik, bár hiányzik belőle az asztali böngészőben elérhető robusztus JavaScript hibakeresési környezet. Mégis, a JS hibakeresőn kívül az Inspect rendelkezik a legtöbb dologgal, amire szükséged van: CSS/HTML-ellenőrzés és JS-konzol, így legalább console.log
hibakeresést végezhet.
Az Inspecthez hasonló fejlesztői eszközalkalmazás hiánya volt az első számú akadálya a webalkalmazások fejlesztésének az iPaden 2018 előtt. Csupán ezekkel az eszközökkel webalkalmazás-fejlesztést végezhet az iPadről. Nagyszerű lesz? Nem tudom. Valószínűleg nem.”
So There You Have It
2019-ben az iPad és az iOS alapvetően ugyanolyan, mint 2017-ben volt, ami a programozást illeti. Ami más, az az iOS alkalmazásfejlesztők növekvő száma, akik olyan embereket szolgálnak ki, akik iOS-en akarnak kódot írni.
Mivel az iOS 12 évvel ezelőtt jelent meg, és csak most állnak rendelkezésre a Dreamweaverhez hasonló szövegszerkesztők, és a “tanulj kódolni” alkalmazásokon kívül kevés lehetőség van a kód futtatására, azt javaslom, hogy 2037-ben már egy iPaden is tudsz majd kódolni.
Vélemény, hozzászólás?