Ale Nuno, pisanie klienta na Androida, jak to ująłeś, "niezaleznego", jest, sory, do bani! Zgadzam się z Dawidem, że wszystkie aplikacje muszą być tak spujne, jak tylko się da. Jesteś jeszcze młody, głowę masz pełną pomysłów, za pół roku rzucisz szpadelek i trafisz piachem Dawidowi w oczy!
Obydwa rozwiązania mają swoje wady. Dwójeczka taką, że ni dość, iż prace nad wieloplatformowym silnikiem tracą sens, to jeszcze ryzykujemy bezpieczeństwem chociażby. Widzieliście, ile ataków było na serwer, skoro tylko najmniejsza luka się otwierała? Skoro jest ktoś tak zdesperowany, chcecie otwierać mu niezależną, trzecią instancję, w której mogą być jakieś tam kolejne błędy? Plus, to niepotrzebne pisanie dwa razy tego samego. A co do jedynki, to znowu robota bez sensu, miesiące pracy, by potem wszystko stracić.
#StandWithUkraine
Shoot for the Moon. Even if you miss, you'll land among the stars.
@pajper Chcesz współpracy i pomocy? W takim wypadku ilu proramistów już pracuje, ilu przyłączy się w najbliższej przyszłości i co jest do "wspulnego opracowania"?
Julito, znasz doskonale odpowiedź na pierwsze pytanie, niepotrzebnie więc je zadajesz. Ale, drugie jest słuszne, bo jest tym, które należałoby zadać. Zastanówmy się. Zgłasza się chętny programista i mówi, że coś by zrobił, ale nie wie, co. Ja w tej chwili widzę dwie opcje: 1. zaimplementowanie podziału wiadomości na konwersacje na stronie tak, jak w kliencie, bo tam wciąż jest lista, 2. ogarnięcie katalogu mediów.
Jeśli zaś chodzi o aplikację mobilną, może ktoś napisać silnik dla Androida. Ale, w Rubym, spójnie z obecnym kodem. Jeśli ktoś się podejmie, jestem otwarty na współpracę, kod jest przeze mnie na bieżąco dokumentowany, jeszcze niepubliczny ze względów bezpieczeństwa, ale jeśli ktoś chętny, podzielę się z nim tym, co mam.
#StandWithUkraine
Shoot for the Moon. Even if you miss, you'll land among the stars.
Nie, bo to musi być ruby i nazewnictwo, koncepcje i wszystko inne muszą być takie same. To ja mam dla Ciebie propo, Nuno. Zacznij się uczyć ruby'ego tylko po to, by móc rozwijać aplikacje, którą rzecież "I tak się znudzisz za 2 lata" hehe.
Tak, od strony programistycznej. Tu jest bałagan, na który niewiele można poradzić. Nadanie mu jakiegoś sensownego interfejsu. Bo, nim edytorzy zaczną dodawać media i stacje, to musi jakoś wyglądać.
#StandWithUkraine
Shoot for the Moon. Even if you miss, you'll land among the stars.
A, i oczywiście, że wysyłają getem, ale... Wygląda to nieco w inny sposób, niż Ty myślisz. Za wszystkim stoi coś nieco innego, niż tutaj. Wszystko chodzi albo na jsach, albo na językach kompilowanych, i nawet nie próbuj mi teraz wmówić, że nie są szybsze od języków interpretowanych, bo się z Tobą po prostu nie zgodzę i tyle. I co do współpracy. Nie da się jej niestety podjąć, gdyż jeśli już miałaby powstawać jakakolwiek współpraca, to wszyscy, którzy zmieniali cokolwiek, nawet najmniejszą jakąś linijkę usunęli, zmienili zmienną, itd. Powinno lądować tam, gdzie to powinno być, czyli np. najlepiej w prywatnym repo eltena na githubie, bo już github to potrafi, następnie, "szef" jak wy go nazwaliście, sprawdzałby na samym końcu w którymś tam momencie, czy wszystko się zgadza i sam sobie błędy poprawiał, o ile takie wystąpią. A niestety, moi kochani forumowicze, nie da się tego zrobić w taki sposób, gdyż po prostu brak jest chęci współpracy. A ja, w sumie p dwóch latach, bo pierwsza wzmianka o otwarciu kodu Eltena była gdzieś albo w 2016 albo w 2017, się po prostu poddaje i z mojej strony w dyskusji tej i żadnej innej dotyczącej oprogramowania Elten nie usłyszycie i nie zobaczycie. Wesolych świąt i szczęśliwego nowego roku. A, i kod który napisałem dla Linuxa... Jak się przyda, to niech jest. Jak nie, to sio.
Oczywiście, że język kompilowany działa szybciej. Nigdy tego nie negowałem. Po prostu jednak jest to różnica tak niewielka, że nieistotna. Zapytanie z klienta na serwer i tak idzie wiele razy dłużej, niż jest przetwarzane. Co z tego, że czas processingu zapytania na serwerze zmniejszę z 3ms do 1ms, skoro i tak nim się przetworzy, na serwer frunie 20ms, a to i tak w optymistycznym scenariuszu? W tej sytuacji gra jest całkowicie niewarta świeczki.
Ale oczywiście, że nie. Tego się nie robi w zamkniętym repo, tutaj się stosuje Pull Requesty, wszak poto je wymyślono, ideą PR jest proponowanie zmian do kodu. Ale jakoś nigdy żadnego nie otrzymałem, a macie na Githubie do tego przycisk.
#StandWithUkraine
Shoot for the Moon. Even if you miss, you'll land among the stars.
A i jeszcze jedna sprawa, bo widzę tu małą niejasność. API, o które pytał nuno to API do połączeń aplikacji mobilnej z serwerem, protokół JSON. Potrzebne mu było do napisania aplikacji niezależnej. API będzie udokumentowane, ale obecnie nie jest skończone.
Tak sobie Was czytam jedząc obiad i myślę, dlaczego robić raban? Skoro aplikacja jest na GitHubie, kod jest otwarty, dlaczego nie pozwolić zrobić Nunowi klienta unofficial (Zaznaczam Unofficial) z dopiskiem w nazwie? Mało takich klientów powstaje dla większych portali?
Sygnatura to może być w sądzie. Sygnatura sprawy np. :P
poza tym, tak jak było tu pare razy podkreślane, jeżeli komuś się znudzi projekt, to autor dostanie mase roboty, której nie będzie w stanie pociągnąć i nagle okaże się, że aplikacja na androida przestaje być kompatyblina z resztą, a płacz będzie no cóż, na szefa właśnie.
poza tym, wyobraźcie sobie proces aktualizacji. Jak dojdzie coś nowego w eltenie na desktopy, to minie jakiś czas, zanim zostanie to napisane w tej nowej, niezależnej aplikacji.
To twuj mózg sobie faworyzuje IOS. Przecież od początku było wiadomo, że dawid zacznie pisać aplikację najpierw na IOS bo raz, że ma iphonea a 2, statystycznie więcej niewidomych korzysta z ios, czy tego chcesz, czy nie, a po 3. Dawid ma macbooka. Jakieś jeszcze argumenty? --Cytat (nuno69): Mnie tutaj jedynie wkurza wyraźna i aktywna faworyzacja iOS.
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.
- "Intelligence and wisdom is like jam. The less you have, the harder you're trying to spread it arround." - French proverb
This site uses cookies to enhance your experience.
