Aplikacja przenośna bez dostępu do sieci - wybór rozwiązania Opcje

[thek]

Ostatnio dziewczyna poprosiła mnie bym napisał aplikację. W pracy musi ona bowiem pewne rzeczy robić, a dostępne oprogramowanie nie obejmuje pewnych aspektów i to właśnie do nich miałbym napisać trochę kodu. Tutaj sprawa rozbiła się o zastosowanie technologii. Aplikacja ma być typu portable - wrzuta na pendrive. Dostęp do sieci internetowej - zero. Ma być dostępna baza danych relacyjna.
Z początku więc rozważałem sqlite jako plikową i polecono mi także Adobe Air. Z tego co doczytałem (nie znam AA) to jednak chcąc, nie chcąc musiałaby aplikacja i tak mieć jakieś połączenie z serwerem, który serwowałby jej obrabiane dane. Z tutoriali itp. odniosłem bowiem wrażenie, że integrować można HTML, JS, AS, tyle że mi to się zda psu na budę, skoro AS nie znam a muszę mieć logikę biznesową jakąś, bo niestety, ale przyjdzie w tym oprogramowaniu generować raporty itp. a same JS i HTML sobie w takim wypadku nie poradzą. Tutaj po prostu język skryptowy w stylu PHP jest niemal nieodzowny, bo gołych danych nie będę słał od razu do bazy bez walidacji i obróbki, a raportów JS też sobie sam nie wygeneruje.
Trochę popracowałem z google i stanęło na XAMMP lite (php + Apache + MySQL). Sprawdziłem i taka kombinacja działa na bank zgodnie z wymaganiami. Tylko czy da się coś innego zastosować? Może jakaś alternatywa dla mojego pomysłu? Nie chciałbym bowiem się do określonego jednego rozwiązania skłaniać "bo tak mi wygodnie". Może jest jakiś inny prosty "jednoklikowy" serwer Apache+MySQL (ew. sqlite mogę dać, bo to nie problem), bo wiecie jak to jest przy XAMPP... Z pena wejść tu, kliknąć tam, potem jeszcze parę kliknięć tu, a jeśli da się wejdź i kliknij tylko raz jeden plik który postawi wszystko to i wygoda większa (wiem... mogę walnąć bata, który uruchomi odpowiednie exe, ale a nuż jest jakiś jednoklikowy (IMG:style_emoticons/default/winksmiley.jpg) ).

[thek]

Widzę, że moja nieobecność dała pole do wymiany poglądów (IMG:style_emoticons/default/smile.gif)
@wookieb: jak wspomniałem, będzie to typowy CRUD: baza w tle, formularze do wprowadzania danych i ich edycji, generowanie raportów. Chyba nie stanie się nic jeśli powiem, że to będzie obsługa księgowa kasy pożyczkowej. Tak więc kontrola wkładów, wpłat i wypłat, deklaracji przystąpienia do i wypisania z, czy po prostu podjęcia ich. Szczegóły z dziewczyną sobie omawiam w chwilach wolnych czasem.
@batman: wszystko na początku jest głośne (IMG:style_emoticons/default/winksmiley.jpg) Problem z tym, czy potem sie przyjmuje. O ile z AdobeAir można mieć nadzieję na okrzepnięcie jak było z Flashem czy AS ogólnie, to Silverlight wywołuje u mnie mieszane uczucia co do możliwego sukcesu. Owszem, jest fajny, tylko czy to wystarczy? C# i .NET maja już w miarę ugruntowana pozycję, więc o nie się nie boję (IMG:style_emoticons/default/smile.gif) Aczkolwiek C# ma raczej opinię takiego przyrodniego, nieco ekstrawaganckiego, brata C++
@athabus: rozwój idący w ilość procków zamiast ich moc to coś co przewidywano już od początku. Zdawano sobie bowiem sprawę z granicy procesów technologicznych. Co pewien czas granicę się przesuwa, ale na pewno nie przekroczy się dla elektroniki bariery atomowej, bo to elektrony są nośnikami informacji. Są badania nad innymi (białkowe, kwantowe), ale i one będą miały swoje granice. Wielordzeniowośc i wieloprocesorowość są nieuniknione tak czy inaczej. Byłem wiele lat temu na uczelni na wykładzie Intela na temat Hyper-Threadingu (był to okres gdy były przecieki o Centrino, czyli jakieś 2002-2003 ) i tam już mówiono o technologicznej barierze 10nm dla procesorów. Na razie jesteśmy na etapie 32, więc jeszcze mamy trochę czasu, ale zobaczcie co już się dzieje. Mocniejsze i7 o szybszych rdzeniach nie są robione w 32nm, ale na powrót w 45nm(!) i Intel wie, że tylko kierunek idący w ilość a nie prędkość rdzeni jest jedynym sensownym rozwiązaniem na przyszłość i kierunek ku architekturze RISC z odchodzeniem od dotychczasowego CISC by sobie ułatwić synchronizowanie wszystkiego
@phpion: rozumiem Cię... sam mam wszystko na classic i wodotryski możliwe off. Jak wydajność to wydajność. Ale czasem jest tak że człowiek chce zaszaleć, zrobić coś nieco inaczej niż zazwyczaj.

Batman w moim odczuciu dotknął tego z czym ja mam właśnie nieco dylemat. "W którą stronę iść?" Czy pisać aplikację desktopową stricte, czy może ukierunkowywać się na stronę webową, bo oba kierunki coraz bardziej upodabniają się do siebie, czy też bardziej prawdziwie - webowe aplikacje zaczynają przeskakiwać desktopowe pod względem estetyki interfejsu, choć wciąż są w tyle z wydajnością. A że akurat o synchronizacje nie muszę się martwić (tylko dziewczyna to będzie obsługiwać i nie będzie sytuacji gdy więcej niż 1 osoba w tym samym czasie) to tak naprawdę mam pełną swobodę wyboru z języków dostępnych.

Swoją drogą kierunek dyskusji, mimo że odbiega nieco od głównego tematu, to uważam za o tyle ciekawy, że dobrze byłoby kontynuować. Takie swoiste: "Desktop vs Web" developing. Zebranie plusów i minusów różnych języków w obu wariantach z zarysowaniem sensu stosowania, kierunków i przewidywań rozwoju. W necie jest bowiem wiele, ale czesto jest to rozwalone na wielu stronach i myślę, że zebranie tego do kupy byłoby jakimś punktem wyjścia dla niektórych. Nie chodzi mi tutaj jednak o coś w stylu "Który język lepszy", bo to typowy flame. Bardziej bym się skupił na perspektywicznym podejściu do nowo powstających rozwiązań czy też świeżych gałęziach w tych już okrzepłych.