Aplikacje desktop z wbudowaną bazą danych narazie piszę w Java + JPA + Hibernate + Swing do okienek.
I teraz moje pytanie. Patrzę tak na kody pisane z użyciem ActiveRecord i mi się bardzo podobają.
Zastanawiam się, czy nie użyć JRubiego przy następnej aplikacji desktopowej z wbudowaną bazą danych (bardziej rozbudowana aplikacja do fakturowania/rozliczeń).
Aplikację zacznę tworzyć za jakiś rok i tak się zastanawiam, czy nie warto zainteresować się teraz Rubim, by za rok móc już w tym tworzyć produktywnie.
Interesuje mnie wersja języka 1.9. Wydaje mi się, że JRuby za rok będzie już z nią zgodny.
Ale zastanawiam się nad ActoveRecord. Czy obsługuje on wersję 1.9 języka? Nie ma problemów z UTF-8? Czy za rok będzie obsługiwał? I czy nie ma problemów z uzywaniem ActiveRecord w JRuby?
bedzie na pewno
ale co do AR nie jestem pewien jeszcze czy nadal bedzie, pewnie jakos zalecialosc, jest juz tak stary i z nami od poczatku tego wszystkigo ze chyba w Rails 3 i pozniejszych bedzie zanikal, ale w sumie jako taki byc powinien i kod tez raczej zgodny bedzie.
Proponuje się przyjrzeć też Groovie’mu, w Twoim przypadku sprawdziłbym Griffona. Pracuje z Groovy on Grails od ponad roku i mogę śmiało polecić. Korzystam zarówno z Railsów jak i Grailsów. Oba frameworki mają swoje wady i zalety. Z griffona nie korzystałem, ale z tego co się interesowałem to jest on podobny do Grailsów tyle że dla desktopa.
Ruby/Rails:
szybsza praca, brak kompilacji
dużo materiałów do nauki, przykładów
świetna społeczność
rewelacyjne narzędzia do testowania
bardzo dobre narzędzia do lekkiej integracji przez. REST/JSON, ogólnie dużo bibliotek do różnych webowych api
brak dobrych bibliotek do typowych zastosowań enterprise (ciężka integracja np. SOAP), PDF, obsługa poczty
brak dobrych rozwiązań do internacjonalizacji
wiele z bibliotek i pluginów jest marnej jakości, nie utrzymywanych
Według mnie: dobre do projektów typowo webowych małej lub średniej wielkości, zdecydowanie nie dla enterprise.
Groovy/Grails:
znając JAVĘ po tygodniu programowania w GROOVY będzie Ci się wydawało że programujesz w tym od zawsze
… i nie będziesz chciał nigdy więcej wrócić do czystej JAVY
100%-owa integracja z JAVĄ - GROOVY jest nadzbiorem JAVY
bogactwo i jakość bibliotek (po prostu korzystasz z bibliotek napisanych w JAVIE + groovy dodaje parę fajnych bibliotek ułatwiających pracę np. XMLSlurper)
Grailsy działają w oparciu o Spring i Hibernate, co daje duże możliwości - jednocześnie chowa to wszystko pod warstwą abstrakcji dając wygodę taką jak Active Record (niektóre rozwiązania są nawet lepsze np. Criteria)
świetne IDE - IntelliJ (do Railsów używam VIMA i bardzo sobię chwalę ale praca w IntelliJ z Grailsami to przyjemność)
niektóre zmiany w aplikacji wymagają restartu
niestety w developmencie wolniejsze niż RAILS
testy działają za wolno
nie ma tylu fajnych pluginów co Rails
Według mnie: dobre do zastosowania w firmach gdzie do tej pory wykorzystywano JAVĘ, dobrze integruje się w środowisku enterprise.
Generalnie polecam sprawdzić zarówno JRUBY jak i Groovy i wybrać co bardziej Ci będzie pasować.
Zrobiłem jeden średni projekt w Grailsach (na zaliczenie przedmiotu “Java 2 - Enterprise” ) i trochę koloryzujesz (Grailsy mają trochę więcej “ostrych brzegów”), Piachoo, niemniej się podpisuję – jeśli aplikacja webowa musi się dopiąć do istniejącego javowego stosu technologicznego, Grailsy należy sprawdzić w pierwszej kolejności
Co jeszcze Ci nie pasowało w Grails? Mnie wkurza wolniejszy development i słabe testy, reszta wad jest zdecydowanie do przebolenia. Tak jak pisałem niektóre rozwiązania są nawet lepsze niż w Rails (serwisy, lokalizacja, cachowanie hibernate/ terracota, dostęp do obiektów globalnych, joby przez Quartza zamiast crona, uniwersalna obsługa baz przez jdbc, kolejki JMS). Żeby nie zaczynać flema powiem, że generalnie jestem “fanem” obydwu frameworków i uważam, że różni je przede wszystkim miejsce gdzie powinny być stosowane.
Grails - korporacje i firmy gdzie dotąd stosowano JAVĘ lub istnieje potrzeba integracji z innymi enterprajsowymi systemami. Grailsy dają dużą szansę na przyspieszenie pracy, bez utraty enterprajsowych technologii (masz do dyspozycji wszystko co działa na JVM). Jeżeli Twój zespół zna JAVĘ to krzywa uczenia będzie bardzo płaska.
Rails - firmy powstałe na fali web2.0, gdzie integracja jeżeli występuje to w oparciu o lekkie api takie jak np. twitter api, youtube api itp. Może to uproszczenie ale według mnie wszystko co kiedyś zakodowałbyś w PHP możesz teraz zakodować w Railsach (10x szybciej i 100x bardziej elegancko).
Przygotowałem sobie środowisko pracy. Stała się rzecz niemożliwa, gdyż działa mi graficzny debugger JRuby w NetBeans xD Zdecydowałem też, że przeżyję chyba bez JRubiego zgodnego z 1.9.
Poza Unicodem nic wielkiego do tej wersji nie wprowadzono, więc się obejdę. Używał będę więc JRubiego zgodnego z 1.8.7.
Jedyny problem to kodoowanie znaków. Na forum widzę narzekania na Railsy, że szablony są kodowane w ASCII itd, ale pomijając to, gdyż ja chcę używać tylko ORM-a, czy pobieranie z bazy i umieszczanie w bazie polskich znaków sprawia problemy w ActiveRecord lub DataMaperze?
Lekki OT: zastanawiałem się ostatnio dlaczego wszystkie gemy do baz danych, takie jak: sqlite3-ruby, pg, … mają kompilowane dowiązania. Patrzyłem w źródła sqlite3-ruby i ma on dwa “drivery”: native (kompilowany w C) i DL. Jedyne sensowne wyjaśnienie to szybkość działania - ktoś ma jakieś informacje na ten temat? Miałem ochotę poprawić sqlite3-ruby, ale wgryzanie się w te natywne dowiązania zajmuje mi za dużo czasu (korzystają tam z narzędzia SWIK). Po prezentacji Charliego o JRubim stwierdziłem, że skoro Ruby FFI działa na JRuby to byłby dużo lepszym rozwiązaniem w wielu przypadkach. Myślicie, że dowiązania do bazy wykorzystujące Ruby FFI byłyby faktycznie dużo wolniejsze? Problem polega na tym, że ktoś będzie musiał te gemy kiedyś naprawić (wszystkie z nich zwracają stringi w ASCII-8BIT).
edit: doczytałem właśnie post Radarka na ten temat, lecz ciekaw jestem o ile zwolniłaby typowa aplikacja po przerzuceniu jej na DL czy FFI.
Ogolnie - musisz uzyc frameworka,ktory ma adapter do data_objects! Polacam uzycie DO z galezi ‘next’ [1], ktora (w wersji dla JRuby) niemalze w 100% przechodzi testy/specyfikacje. AR posiada adapter dla DO,ale nie jest on w pelni funkcjonalny (patrz konto “rsim” na Githubie). Mozesz uzyc tez Sequel’a (maly wybor baz danych (adapterow) dla JRuby). Zmierzam do tego,ze najlepiej wykorzystac rozwiazanie najnaturalniejsze i skorzystac z DataMapper(data_objects to podprojekt DM) - Masz do wyboru kilka baz wbudowanych dla JRuby. Zapraszam na kanal #dm-hacking -> pomozemy (userzy: myabc, pietia)
Jeszcze odnośnie FFI: przerobiłem na szybko DL na FFI (najważniejsze funkcje powinny działać), odpaliłem benchmark zawarty w sqlite3-ruby (native-vs-dl.rb) podmieniając DL na FFI, zmieniłem liczbę prób z 1k na 10k:
[code]database creation…
user system total real
ffi 3.370000 1.600000 4.970000 ( 4.967909)
native 3.520000 1.470000 4.990000 ( 4.981824)
database open…
user system total real
ffi 3.180000 0.250000 3.430000 ( 3.418751)
native 3.180000 0.160000 3.340000 ( 3.342406)
insertions
user system total real
ffi 0.550000 0.010000 0.560000 ( 0.642694)
native 0.460000 0.010000 0.470000 ( 0.550725)
insertions using prepared statement
user system total real
ffi 0.330000 0.030000 0.360000 ( 0.450778)
native 0.250000 0.030000 0.280000 ( 0.410028)
queries
user system total real
ffi 1.650000 0.110000 1.760000 ( 1.757475)
native 1.240000 0.130000 1.370000 ( 1.369390)[/code]
Wydaje mi się, że różnice są na tyle małe, że nie powinny mieć żadnego znaczenia. Może byłoby warto przepisać te gemy na FFI, dodając przy okazji obsługę kodowań w 1.9?
@pietia
“rubygems.rb:827:in `report_activate_error’: RubyGem version error: extlib(0.9.9 not ~> 0.9.14) (Gem::LoadError)”
Skąd pobrać wersję 0.9.14? Nawet na githubie znalazłem jakąs niby 0.9.14, ale okazało się, że to 0.9.9…
Mam problem z dm-core. Pi wpsianiu jruby -S rake clean install
wywala mi: no such file to load -- hoe
E:/Program Files/Ruby/.../rake.rb:2383 "raw_load_rakefile"
E:/Program Files/Ruby/jruby-1.4.0/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in require': no such file to load -- do_jdbc_internal (LoadError) from E:/Program Files/Ruby/jruby-1.4.0/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:inrequire’
from E:/Program Files/Ruby/jruby-1.4.0/lib/ruby/gems/1.8/gems/do_jdbc-0.10.1-java/lib/do_jdbc.rb:4
from E:/Program Files/Ruby/jruby-1.4.0/lib/ruby/gems/1.8/gems/do_jdbc-0.10.1-java/lib/do_jdbc.rb:36:in require' from E:/Program Files/Ruby/jruby-1.4.0/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:inrequire’
Poradziłem sobie z tym. Okazało się, że nie skompilowałem źródeł Javy. Mam następny problem:
E:/Program Files/Ruby/jruby-1.4.0/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in require': no such file to load -- jdbc_adapter (LoadError) from E:/Program Files/Ruby/jruby-1.4.0/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:inrequire’
from E:/Program Files/Ruby/jruby-1.4.0/lib/ruby/gems/1.8/gems/dm-core-0.10.2/lib/dm-core/adapters.rb:123:in load_adapter' from E:/Program Files/Ruby/jruby-1.4.0/lib/ruby/gems/1.8/gems/dm-core-0.10.2/lib/dm-core/adapters.rb:101:inadapter_class’
from E:/Program Files/Ruby/jruby-1.4.0/lib/ruby/gems/1.8/gems/dm-core-0.10.2/lib/dm-core/adapters.rb:13:in new' from E:/Program Files/Ruby/jruby-1.4.0/lib/ruby/gems/1.8/gems/dm-core-0.10.2/lib/dm-core.rb:171:insetup’
) i trochę koloryzujesz (Grailsy mają trochę więcej “ostrych brzegów”), Piachoo, niemniej się podpisuję – jeśli aplikacja webowa musi się dopiąć do istniejącego javowego stosu technologicznego, Grailsy należy sprawdzić w pierwszej kolejności 