Play! 2 JAVA web freimworks

[codez]

Jau sen ir bijusi vēlme izkāpt no PHP un iekāpt kādā labākā izstrādes vidē, bet vienmēr ir bijuši pietakami daudz iemesli, lai to nedarītu un, lai arī PHP ir simtiem trūkumu, tam ir bijuši arī daudzi plusi, kas lika nosvērties par labu PHP. Ir mēģināts gan pythons, gan node.js, gan JAVA ar tās tobrīd populārākajiem FW, bet vienmēr esmu palicis pie PHP kā web aplikāciju kodola.

Taču tagad šķiet viss var mainīties. Esmu atradis JAVA Play! 2 FW. Līdz tam izstrāde JAVA bija sarežģīta un bija jāraksta daudz gara koda, jāmācās sarežģītas konfigurācijas, jātaisa build vides (ant, maven), utt.

Kas savādāk ir Play! FW.

Lai izveidotu Hello world projectu, vajadzīgi sekojoši soļi:

1)nokopējam play FW,

2)aizejam uz projekta mapi un ar vienu komandu izveidojam projektu

 

play new myproject

3)Ieejam /app/controllers mapē un izveidojam HelloWorld.java

package controllers;
 
import play.mvc.Controller;
import play.mvc.Result;
 
public class HelloWorld extends Controller {  
  public static Result index() {
    return ok("Hello World");
  } 
  
}

 

4) ieejam conf/routes failā un pievienojam jaunu ceļu:

GET     /hello                      controllers.HelloWorld.index()

 

5)palaižam komandu "play run" un ejam uz localhost:9000/hello

Play! FW pats nokompilē javas projektu pie pirmā requesta un mēs uzreiz redzam rezultātu, kas, saprotams, kā PHP programmētājam, ir absolūti nepieciešama lieta.

Play! izmanto savu iekšēju serveri. Sākt strādāt pie jauna projekta, vai uzbūvēt savu pirmo Hello World projektu var, praktsiki neko neapgūstot, dažās minūtēs.

 

Kādi ir galvenie Play! FW plusi manā skatījumā:

- Ir viss, ko vien no FW var vēlēties - jaudīgi modeļi, jau iebūvēts kešs, kurš strādā uzreiz, bet produkcijas gadījumā varam aizvietot ar memcached, iebūvēta testēšana - JUnit, Selenium, modulāra arhitektūra, viens konfigurācijas fails, kurā pat neko daudz nevajag konfigurēt, jo defaultā jau viss strādā, iebūvēt automātiska coffee script kompilēšana, less css kompilēšana, moduļu kompilēšana priekš RequireJS. Ir pat javascript routeris priekš dinamisku ceļu definēšanas javascriptā (piem. ajax requestiem). 

- Asinhrons I/O (tas pats, kas nodejs), kas ļauj ar mazu RAM patēriņu nodrošināt lielu skaitu paralēlu konekciju un lielu skaitu pieprasījumu. Tas ļauj arī vienkārši izveidot Commet un Websocket pieslēgumus (nodejs ar tās socket.io gan tas pagaidām ir vēl nedaudz vienkāršāk).

- Scala - moderna funkcionāla valoda. Jebkuru aplikācijas daļu var jebkurā brīdī rakstīt scalā.

- Pietiekami daudz un pat lielas kompānijas ievieš šo FW lielas slodzes produkcijas vidēs, piemēram LinkedIn: http://engineering.linkedin.com/play/play-framework-linkedin

- ērta estētiska dokumentācija ar daudz labiem tutoriāļiem un piemēriem.

 

Pagaidām esmu pavadījis 1 dienu šijā FW un man tikpat kā nav JAVA pieredzes, bet jau principā esmu spējīgs veidot web aplikācijas bez īpašas aizķeršanās (ja neskaita, ka brīžiem ir vajadzīgs apgūt pašu JAVA vai SCALA valodu), jo pats Play! FW ir ļoti vienkārši saprotams un intuitīvs.

Edited March 29, 2013 by codez

[daGrevis]

Interesanti. Man kko tomēr liekas, ka Java ir par verbousu priekš web appiem.

[codez]

daGrevis, jā tā bija līdz šim un vienmēr, kad esmu mēģinājis ar JAVA būvēt web aplikācijas, aptīte pārgāja ļoti ātri, taču ar Play! 2 viss ir savādāk. Cik esmu lasījis citu atsauksmes, daži pieredzējuši JAVisti pat saka, ka izstāde pat nelīdzinās līdz tam pierastajai JAVAi.

Pietam jāņem vērā, ka JAVA galu rezultātā ir ļoti ātra un apvienojumā ar event driven asynchronous I/O, tā ir ļoti ātra. Vienkāršu requestu ģenerācija aizņem dažas ms, pat pie liela skaita paralēlu konekciju. PHP FW gadījumā mēs parasti runājām par dažiem simtiem ms.

Edited March 29, 2013 by codez

[daGrevis]

Vai webappām vajag ekstra ātrumu? Līdz šim performace bija _good enough_.

[codez]

Protams, ātrums starp simtiem ms un desmitiem ms webappu izstrādē nav pirmā svarīguma jautājums, taču tas ir vismaz trešā svarīguma jautājums, bet paliek par otrā vai pat pirmā svarīguma jautājumu, kad aplikācija ir kaut nedaudz jāskeilo.

Taču, ja mums ir divas ērtas izstrādes vides, bet viena dod 5x ātrāku aplikāciju, tad tas ir pietiekami labs aguments, lai to izvēlētos.

 

Vēl kas PHP nekad nav apmierinājis, lai gan daudzi to uzskata par plusu, ir dinamiskie tipi, jo praktiski visas kļūdas rodas nekā cita dēļ, kā dinamisku tipu dēļ. Statisku tipu gadījumā gandrīz visas kļūdas jau tiek novērstas IDĒ. Pie tam ar statiskiem tipiem visi intelisense strādā daudz labāk. Un saistībā ar to esmu novērojis, ka pēdējos PHP projektos tik un tā visām metodēm tiek rakstīta klāt dokumentācija ar parametrus un atgriezto vērtību tipiem, lai intelisense varētu saprast, kas ir kas. Un, ja jau tas tiek darīts, tad kāpēc neizmantot uzreiz statisku tipu valodu.

[rpr]

da grievi, tad tev ir līdz šim bijuši niecīgi projekti. kaut vai tie paši draugi, nemaz nerunājot pasaules līmeņa sociāliem tīkliem uttt ir vienmēr cīnījušies ar ātrdarbības problēmām.

[daGrevis]

Patreizējais projekts ir uz Python un vidēji ir 30'000 aktīvi, online-now lietotāji. Python performance (dinamiska, interpretējama valoda — līdzīgāka PHP nekā Javai) nav bijusi problēma. Jebkurā gadījumā, performace-critical lietas var pārrakstīt uz C — nav problēmu. Un par statiskajiem tipiem — duck typing ir pamatīgs boosts developer laikā un tas ir svarīgi.

[rpr]

nekad neesmu sapratis ko nozīmē n lietotāji. vari pateikt konkrēti cik rekvestus/dienā (stundā vai sekundē) vari ar savu pitonu apstradāt?

[spainis]

bet kāds ir ar pārējais setups?

[codez]

 Un par statiskajiem tipiem — duck typing ir pamatīgs boosts developer laikā un tas ir svarīgi.

No vienas puses, jā, bet reāli, cik bieži ir vajadzīga tāda tipu jaukšana?

Turpretī, ja kādā vietā pamanīsies uzrakstīt nepareizu parametru, vai objekta propertija vietā, piemēram, ielikt pašu objektu, tad kļūdu pamanīsi tikai runtimā un tikai tad, kad izpilde nonāks līdz dotajai vietai, vai pat vēl trakāk - kods var nostrādāt bez runtime errora, jo pekšņi dotais objekts izskatās pēc "pīles" un palikt nepamanīta kļūda, kamēr statisku tipu gadījumā kļudu pamanīsi jau IDĒ, tikko kā būsi to uzrakstījis.

[daGrevis]

> jo pekšņi dotais objekts izskatās pēc "pīles" un palikt nepamanīta kļūda

 

Bet ja tā izskatās pēc pīles un kakšķ kā pīle, tad tā ir pīle! Tā jau ir tā burvība.

 

Also, testi.

 

> cik bieži ir vajadzīga tāda tipu jaukšana?

 

Ļoti atkarīgs no valodas. Pythonā tas ir ļoti bieži.

 

> vari pateikt konkrēti cik rekvestus/dienā (stundā vai sekundē) vari ar savu pitonu apstradāt?

 

Nevaru, tagad nav pieejami konkrēti dati. Bet, teiksim, YouTube ir rakstīts Pythonā. Un simts un viena high-performance aplikācija ir rakstīta PHP. Un tikpat arī Ruby. Visas šīs valodas ir dinamiskas. Un JavaScript ir dinamiska valoda. Un V8 dažās vietās pārsit pat C. Un ir Jit. Un Lua ir super-ātra. Tik ātra, ka tā tiek izmanota kā high-performace spēļu sktiptošanas valoda. Un atkal ir Jit. Ir PyPy un ir Topaz. Pēc teorijas statiskās valodas ir ātrākās un tā, praksē, tukšos benčmarkos arī ir, bet, arī, praksē šie testi neko nedod un neviens nekad nav teicis: «Ai, mūsu aplikācija visu bremzē — vajadzēja izvēlēties statisko valodu». Ir citi, daudz svarīgāki, kā saka, botlneki. Piemēram, IO.

 

> da grievi,

 

Bļāviens, nu!

[rpr]

nu youtube jau nav viens serveris un tur jau isti nav iespejams salidzinat cik serverus vajadzetu ar php, cik ar py, cik ar java. viss ir konfigurejams un relativs.

[daGrevis]

Tas gan. Yet, Py nav bijusi problēma.

[daGrevis]

Vai ar Scalu var izmantot Play?

[codez]

Vai ar Scalu var izmantot Play?

Jā, patiesībā Play2 pat ir labāk pielāgots tieši scalai.