No dobra, to wyobraź sobie proces aktualizacji aplikacji IOS i androidowej. Zamiast zrobić to za jednym zamachem, będzie dużo zabawy. --Cytat (nuno69): Tak, bo na pewno kod będzie w 100% kompatybilny między desktopem a mobilką. Nie piernicz pan.
A o jakiej kompatybilności ty mówisz, jak tobie zależy, z tego co czytam na oddzielnej, niezależnej aplikacji na androida nie bazującej na tym, co już jest? --Cytat (nuno69): No OK, ale w takim raziie twój argument o tej słynnej kompatybilności też leży, gdyby wszystko było na miodzio kompatybilne, to pisałbym to z ciepłego łożeczka.
Nie powiesz mi, chociaż nie wiem jak byś się starał, że będziesz miał tyle samo roboty przy aktualizacjach w tej swojej niezależnej apce niż kiedy wszystko jest bardziej spójne. Nie powiesz mi, chociaż nie wiem jak byś się starał, że generuje to tyle samo roboty. --Cytat (nuno69): Będzie tyle samo co z mojąą czy czyją kolwiek inną, też będzie to kwestia dopisania odpowiednich funkcji i odwołan do API.
Jak jeszcze baza sama w sobie nie jest ukończona, to po co na raz robić dwie bety?--Cytat (nuno69): No taka, ze gdyby baza kodowa byla tak kompatybilna jak mowisz, to bylaby beta rownolegle na iOS i Androida.
No i się okazuje, że prawdę napisał dawno temu Zbigniew Nienacki, że autor staje się niewolnikiem swojego dzieła, więc wyrazy współczucia dla Dawida. A z innej beczki - Xamarin jest lipny z różnych powodów, np. wydajności, więc bym się na niego za bardzo nie nakręcał. Jedyne dwa języki, które na dzień dzisiejszy się nadają do użytku, bo pracują praktycznie na wszystkim, to Javascript do wysokopoziomowych i c++ do niskopoziomowych zadań. No jest jeszcze popularny PHP, ale z tego co kojarzę, to NODE JS, też bazujący na Javascript, jest wydajniejszym serwerem, chociaż osobiście go nie używałem. I żeby nie zaczynać offtopa, to nie chodzi mi o udowadnianie wyższości jednego języka nad innym, Grmapę napisałem we Freepascalu, więc oczywiście że niech każdy pisze w tym co mu pasuje. I nie jestem fanem JS, ale nie mogę go nie doceniać, skoro mając webappkę zrobioną raz, można ją odpalić na praktycznie każdej przeglądarce czyli jednym strzałem na wszystkim włącznie z urządzeniami mobilnymi a możliwości nowoczesnych przeglądarek takie jak webAudio sensor api, czy wreszcie z naszego podwórka ARIA są nie bez znaczenia. Z tymi włamaniami i bezpieczeństwem, to klienty nie mają tu nic do rzeczy, bo serwer musi być odporny, a klienty mogą być dowolnie zapluskwione i co najwyżej nie zadziałają. Nie wiem czy jest sens robienia czegokolwiek ze stroną Eltena, skoro aktualnie istnieją dwa serwery Eltena, tj. stary obecnie używany i nowy bazujący na JSON, a strona oparta jest na starym serwerze. Dopisywanie choćby jednej linii do starego serwera, żeby umożliwić zrobienie czegoś na stronie, to jest puszczanie pary w gwizdek. Więc kolejność działań się wydaje następująca: 1. Pozwolić Dawidowi ustabilizować API nowego serwera, które powstaje równolegle z apkami mobilnymi. 2. Po wykonaniu tego kroku, poprosić autora o udokumentowanie API, albo zrobić to samemu na bazie analizy kodu nowego serwera napisanego w PHP. 3. Droga wolna, można pisać progressive webapps na wszystkie platformy w JS, konwertować je później do apek natywnych z Nativescript, albo czymś co aktualnie będzie w użyciu. Czy ktoś ma jakiś problem z tym, że istnieją oficjalne apki dużych portali, a równolegle api na którym ludzie tworzą nowe rozwiązania, które przestają działać, gdy api się zmieni? Oczywiście punkt 1. jest czasochłonny, ale bicie piany na forum nie skraca czasu jego wykonania, skoro autor traci czas odpowiadając na forum, który mógłby poświęcić na pisanie następnych linii kodu. I jeszcze jedna kwestia - efektywność zespołu programistów. Jeśli jeden człowiek ogarnia całe zagadnienie, to jest je w stanie w miarę spójnie oprogramować i łatwo panuje nad całością. Jeśli dołącza do niego ktoś drugi, to niby powinno wszystko iść dwa razy szybciej, ale wcale tak nie jest, bo trzeba się dzielić pracą, wymieniać pomysłami, ustalać wspólne koncepcje. Gdzieś słyszałem, że przy dopiero chyba 4 osobach, ten narzut związany z przepływem informacji się zaczyna opłacać, ale z kolei zbyt duży zespół się zatyka komunikacyjnie, więc na prawdę duże rzeczy, się robi tak, że najpierw powstaje spójny projekt systemu, dokładnie opisany, który później można połamać na kawałki i rozdać programistom, bo każdy dokładnie wie co dostanie na wejściu i co ma zwrócić na wyjściu. Czy Elten jest dużym projektem? W kontekście powyższego, raczej nie, tj. spokojnie może zostać ogarnięty i oprogramowany przez jedną osobę. A z drugiej strony, jest mnóstwo rzeczy pożytecznych dla środowiska niewidomych, a nie związanych z Eltenem, którymi można i warto się zająć do czasu ustabilizowania api nowego serwera, więc sfrustrowanym kolegom proponuję szersze spojrzenie na bardziej twórcze możliwości spożytkowania posiadanej energii i potencjału intelektualnego.
Grzezlo nie stary serwer i nowy serwer, tylko nowe api dla aplikacji mobilnych, i tak korzystające z starego serwera. Ehh, a ponoć miałem się nie wypowiadać :D
Miałem na myśli serwer w znaczeniu softwarowym, czyli napisany w PHP skrypt/skrypty dostające zapytanie i udzielające odpowiedzi. Czyli że nowe api będzie używało starego kodu w PHP? Byłby to pomysł dość osobliwy zwłaszcza w kontekście fajnej stopki, którą znalazlem kiedyś pod wpisami kogoś na forum programistycznym: jeżeli patrzysz na swój kod napisany 2 lata temu i wydaje ci się on czymś więcej niż odchody, to znaczy, że się nie rozwijasz. I coś w tym jest, bo gdy myślę o poprawianiu czegoś zrobionego przez siebie dawniej, to jedyna myśl jaka mi do głowy przychodzi, że właściwie to trza by to w kosz wrzucić i od nowa napisać.
Z tego co zrozumiałem to on ma bazować na tym. No bo po co pisać od nowa wszystko? Klienty desktopowe będą na serwerze w php, a mobilki na tym drugim, który chyba też z tego serwera będzie wszystkie dane czerpał.
@Nuno69: Nie można porównywać języków, a jedynie silniki, które te języki interpretują lub kompilują. A nie mogę teraz szybko znaleźć porównania Xamarina, o którym pisałem. JS działa na wszystkim, jeśli komuś to mało, to jest jeszcze webassembly i emscripten, którym do wasm można kod z c/c++ kompilować i działa to w przeglądarce z wydajnością zbliżoną do natywnej. A dla apek mobilnych, jeśli potrzebna jest rzeczywiście wysoka wydajność, można robić biblioteki w C++ które się na wszystko skompilują do binarek natywnych i dają podłączać do IOS / Androida. Cały web się opiera na js, więc jest mnóstwo ludzi i firm zainteresowanych rozwojem tych technologii i jak widać, nie źle im to wychodzi. Nawet Apple się ugieło i zaimplementowało Service Workers w Safari IOS, teraz tylko czekamy na webPush czyli powiadomienia na zablokowanym ekranie. A jakieś tam CSharpy, Ruby, Java czy nawet mój ulubiony Freepascal, to są niszowe rozwiązania. No i piszę to nawet mimo faktu, że w rankingu Tiobe ciągle ta marna Java na pierwszym miejscu i to z tendencją lekko wzrostową. Gdybym był na etapie edukacji szkolnej, to właśnie na JS i C++ bym zwracał uwagę, żeby się w nich wyspecjalizować, ale może się mylę i JS odejdzie w niepamięć razem z większością sieci web, a jakieś niszowe rozwiązanie się rozwinie. A może właśnie dobrze jest się nauczyć dowolnych 4 języków, które aktualnie wpadną w łapki, no a każdy następny to już będzie z górki. Sorki za offtopic, może osobny temat z tego moderacja wyciągnie, to sobie swobodniej pogdybamy?
I tak tu jest burdel :), a tu rzecowa dyskusja sie szykuje Powiem ci tak, jak dla mnie, CPP jak najbardziej ale C# na prawde ni jest zly, owszem, takie rzeczy jak rendering hyper zaawansowanych grafik lepiej jest robic przy pomocy C++ czy nawet C, bo jak wiadomo C# zwwalnia duzo przez JIT i wogole przez IL. O WASM nie slyszalem, i szczerze: zaciekawiles mnie.
- "Intelligence and wisdom is like jam. The less you have, the harder you're trying to spread it arround." - French proverb
Też niedawno się z tym WASM spotkałem przy okazji udanej próby odpalenia starych szachów mówiących dla dosa w przeglądarce idąc torem zapaleńców, którzy przez webassembly odpalili emulatory linuxa, czy różne stare gry typu doom.
@grzezlo a ja bym nie szedł w takie porównania. Język to język, ma swych fanów i przeciwników. Rzeczywiście JS jest ważny, ale i ograniczony, pewnych rzeczy w nim się nie zrobi, inna sprawa, że staje się coraz popularniejszy. Od strony serwerowej wciąż przoduje PHP, chociaż i Rubiego coraz więcej. Nie podejmowałbym się szacowania, jaki język daje największe możliwości - śledząc zlecenia dla programistów widzę zarówno CPP, Pythona, Javę, Rubiego... Trudno szacować.
Ale, by wróćić do tematu wątku. Nie wiem czy warto, by nowa strona bazowała na API po JSONie. Oczywiście, ma to swoje zalety znane, ale wydajnościowo jest słabsze. Nie wiem czy strony nie rozwijać dalej, jak jest - skrypty php łączące się bezpośrednią z bazą sql. Oczywiście, ma to swoje wady, większe ryzyko bezpieczeństwa szczególnie, ale i zalety: wydajność.
Co do starego serwera, nie wyłączę go, chociażbym chciał, bo to, co 4 lata temu pisałem jest... no... masakryczne. Ale, kwestia kompatybilności wstecznej...
#StandWithUkraine
Shoot for the Moon. Even if you miss, you'll land among the stars.
Jeśli będzie nowy serwer na JSON, to nie ma odwrotu od przepisania strony na wywołania z JS właśnie dlatego, żeby nie utrzymywać słabych staroci, które potencjalnie mogą być wektorem ataku i blokują rozwój przez konieczność zapewnienia kompatybilności wstecznej. A weź mi wyjaśnij taką rzecz: Idzie zapytanie do serwera w PHP, który zwraca 80 kilobajtów kodu HTML odpowiedzi. Te 80 kilobajtów musi zostać następnie zinterpretowane i zrenderowane przez przeglądarkę. No to jak to może być bardziej wydajne od wysłania zapytania w JSON i odebrania odpowiedzi też w JSON (kilka kilobajtów) którą się następnie szybko zrenderuje w przeglądarce? No i w takim trybie starego typu wywołań, nie możesz sensownie korzystać z ARIA bo się strona co chwila przeładowuje, a w nowym typie, spokojnie możesz. Czyli np. jest funkcja w JS odpytująca okresowo serwer co nowego, a użytkownik sobie spokojnie czyta zawartość strony. Jeśli przyjdzie coś nowego, to się odtwarza przez webaudio dzwoneczek, no i generuje powiadomienie tekstowe, automatycznie odczytane przez aria-live. Czyli wtedy masz jeden serwer, który rozwijasz, stabilne api, no i parę klientów: strona web, klient desktopowy, apki mobilne i cokolwiek do głowy przyjdzie. A jak ktoś zechce napisać tekstowego klienta dla terminali linux, też ma taką możliwość.
This site uses cookies to enhance your experience.
