IT Industrija
🔥 Najčitanije
🔥 Najčitanije
Krajem decembra sam stao pred okupljene inženjere Bal Laba i objavio — “Nadalje više nećemo raditi PHP i podržavaćemo samo Javu.”
Za kompaniju koja je prethodne 3 godine podjednako gradila sa PHP-om i Javom, i ima veliki broj izuzetnih PHP inženjera, ovo je u najmanju ruku bilo veliko iznenađenje za tim. Ova odluka nalaže obrazloženje i može doprineti uvek prisutnoj PHP vs. Java diskusiji.
Java — lingua franca big data sveta
Prvo moramo sagledati organizacijski kontekst pre nego što uronimo u tehničke razloge. Tokom prošle godine u Bal Labu smo se sve više fokusirali na projekte zasnovane na skalabilnosti i near-realtime procesiranju i, najvažnije, big data analitici.
Kako se Java (i JVM jezici poput Scale) uspostavljaju kao lingua franca za big data, to nam daje vrlo smislen i direktan razlog da promenimo platformu sa kojom radimo.
PHP je izgubio oštricu
Zašto smo uopšte radili sa PHP-om? U ranim fazama je delovalo da PHP ima svoje prednosti nad Javom u brzom “UI driven application developmentu“.
Nažalost, moje je mišljenje da je Java, u kombinaciji sa frejmvorcima poput Springa, AngularJSa i Twitter Bootstrapom, uspešno prevazišla svoja ograničenja kada je u pitanju brzo i lako građenje veb aplikacija.
Spring je ispred Laravela ili Codeignitera
Postoje brojni prvoklasni frejmvorci za Javu, kao što su Spring, Jersey, Play i Spark (sjajan projekat, pogledajte ako niste). Spring je jasan izbor kada je potrebno razvijati kompleksne aplikacije.
Ako pogledate ogroman broj podržanih tehnologija i izvanredan kvalitet dokumentacije Springa biće vam jasno da je Spring daleko ispred Laravela i sve manje aktuelnog CodeIgnitera.
Odsustvo izvanrednog frejmvorka uporedivog sa Springom smatram najvećim neuspehom PHP zajednice. Ovih dana čak i mali veb startapi zahtevaju više od čistog ORM-a i MVC-a.
Frejmvorci kao organizacijski alati
Kako organizacije rastu tako frejmvorci postaju sve kritičnija karika u lancu razvoja softvera. Dobro definisani, naširoko korišćeni i dobro dokumentovani frejmvorci poput Springa su ključni za rastuće organizacije zato što im dozvoljavaju da usvoje zajednički set standarda za razvoj.
Naše iskustvo je da smo uspeli da on-boardujemo čak i diplomce ili PHP inženjere tako da su bili produktivni uz sjajne rezultate sa Javom za manje od dva meseca, uz naše interne treninge i posebnu “boot” aplikaciju za Spring.
Nijedan PHP inženjer nije povređen tokom ovog procesa!
Na kraju moram da kažem da se nijedna odluka ove vrste ne može doneti bez razmišljanja o inženjerima; utoliko pre od strane nekoga poput mene ko i sam svaki dan piše kod. Kada sam objavio novost učinio sam kristalno jasnim to da će svi PHP inženjeri biti glatko prebačeni na Javu.
Ujedno sam i savršeno siguran da svaki pojedinačni inženjer u organizaciji može da lako obavi tu tranziciju pošto inače ne bismo ni bili zajedno u timu.
Programerske platforme su samo alati, i sjajni inženjeri lako mogu da izaberu najbolji alat za posao pred njima. Pitanje nije toliko da li je PHP bolji od Jave, već pre to koji je najbolji alat za nas u Bal Labu za ovu fazu naše evolucije.
Ivan
ponedeljak, 29. Februar, 2016.
Toliko price pricate svi,a retko ko je i pomenuo zasto se uopste prelazi sa jezika na jezik-Potvtdjeno je (dakle dokazano) kao u matematici da se jedan problem moze resiti na vise nacina,pa tako i programeri mogu da biraju implementaciono sredstvo za resenje svojih problema.Ja biram od svake tehmolopgije najbolje.-naravno kada se pitam i kada mogu da biram--Imate firme koje samo radi sa open source resenjima pa za teze stvari sve ide preko stapa i kanama .Baza :Uvek ORACLE -visoka skalabilnost,paralelni rad sa vise desetia korisnika-konekcija,sesija kako god,PHP ako treba obrada na serveru -zend framework itd...
Ivan Mojsilovic
petak, 20. Februar, 2015.
Good old Java. We've used Symfony (SF) from the version 1.1 up to 2 and since we were native Java devs it was interesting to watch how SF is trying to catch up with JPA specs (among others).
Nemanja K.
sreda, 11. Februar, 2015.
@bal I guessed it's possible with Spring Data JPA but did not worked on such problems so I backed off and did not want to guess. It's true although that SF2 and Spring are moving toward similar goal since best practices are not dependent on programming language itself. Main diff is that they are moving from opposite starting points. Pure Java and pure PHP are pretty different.
bal
sreda, 11. Februar, 2015.
@Zeljko , @Nemanja - If I understand the comment right. The upsert + data transformer pattern that is described is supported out of the box at multiple levels 1. JPA (Java Persistence Architecture) 2. Hibernate et al as ORM implementation of the JPA standards. 3. Spring Data JPA. with the original support being provided probably as way back as 2010. And as one would probably remember Doctrine & Propel of course have their origins in Hibernate and Torque respectively. For a good intro to JPA try this : http://www.petrikainulainen.net/spring-data-jpa-tutorial/
Zeljko
sreda, 11. Februar, 2015.
@nemanja Steta, ali verujem da ce se uskoro pojaviti. Dobre ideje se 'kradu' i cim neko napravi DT za Spring, posao ce ti biti mnogo laksi. Sto se tice rabbit-a; nemam licno iskustvo i postavicu ga tek za oko 3-4 nedelje. Ono sto sam dosad gledao jesu dokumentacija i primeri i nijedna kritika nije bila na racun trosenja previse resursa. Ali jos jednom; nije licno iskustvo vec iskustvo drugih. PHP moze da se probudi iz sleep-a kad mu stigne signal ali pravo da ti kazem, ne bi me ni najmanje cudilo da koriste javu u celog prici :)
Nemanja K.
sreda, 11. Februar, 2015.
@Zeljko Pogledao sam sada SF2 dokumentaciju jer se sa data-transformerima nisam susretao. Mislim da nesto tako ne postoji u Springu - barem ne "out of the box". Sto se tice RabbitMQ-a, bio je u opticaju ali se odustalo jer je effort bio priblizno isti (tek kad smo poceli implementaciju naleteli smo na problem nekompatibilnosti libgearman-a iz ubuntu repo-a i PEAR ekstenzije). Nisam detaljno prolazio kroz SDK Rabbit-a za PHP ali ne vidim kojim PHP mehanizmom bi obezbedi asinhronu obradu dolaznih poruka u jednom procesu-u?
Zeljko
sreda, 11. Februar, 2015.
@Nemanja Svaka cast za komentar, izneo si argumente na vrlo ozbiljan nacin. Ali mislim da ste pogresili za Gearman, RabbitMQ radi bez kreiranja bespotrebnih procesa. Zanimaju me druge tehnologije pa imam jedno ozbiljno pitanje; da li Spring ima data-transformere? Na primer; imas stranicu za editovanje proizvoda ali umesto select-a za odabir kategorije, ti imas obican input (recimo da imas mnogo kategorija i ne zelis da browser poludi). S2 ce lako da pronadje entitet po ukucan tekstu ili da kreira novi ako treba. Kako se Spring snalazi sa tim?
bal
sreda, 11. Februar, 2015.
@Djordje - Thanks for the feedback. This blog format forces one to highly compress the initial thoughts. And in my own defense I did say that this has to do with Big Data. Lesson learned - write longer (and dont mess with PHP ;-).
Mikica
sreda, 11. Februar, 2015.
@Zeljko (promaja013), izvinjavam se, u pravu si da nema potrebe za sarkazmom. Ja se izvinjavam svima zbog toga sto sam malo vise trolovao i na neki nacin upropastio zanimljivu diskusiju. Moje misljenje je da je programski jezik samo alat,a da treba da izaberemo alat koji najvise odgovora za nas projekat. Ako je neko dobar developer onda taj isti mora da se snadje u bilo kom drugom programskom jeziku.
bal
sreda, 11. Februar, 2015.
@Saša - Thank you for the direct question. I think a couple of the commenters on the article do not take into account the context which is clearly stated in the first few sentences - This is about picking the "appropriate" tool for big-data projects. And now a few comments down the road we have ended in a battle of frameworks ;-) . Getting back to your question, the requirements we are building against are systems that scale across 1000s (yes thousands) of servers and data ingestion rates of a million events per second. Many of these are asynchronous or event driven processes. I will not be able to do a feature by feature comparison but will focus on a couple of things that we need on projects. For doing that we need to go even further back to the infrastructure that serves as the starting point for big-data. Just a few of the technologies that anyone who works with big-data build on - Hadoop, Storm, Apache Spark, Kafka, Flume, Hive, Tachyon, Cassandra , Hazelcast, GridGain, Lucene .... All of these are Java based technologies with quite a few in fact highly dependent on Scala. Simply the aspect of linking into these technologies with PHP and still maintaining a manageable set of code presents a huge challenge. Once you have stepped away from the data access and processing layer we get to the frameworks. The best place to start is probably on the Spring Projects page which gives an overview of some of the key projects within the umbrella of Spring - ( http://spring.io/projects ). It definitely establishes Spring as not just a "Web Application Framework" but one that enables you a level of abstraction that can be used for everything from command line, to desktop, mobile and even what I call "headless apps" (processing chains). Some noteworthy projects among these are Spring XD - Primarily targeted at ingestion and transformation pipelines and big-data processing. Spring Integration which deals with routing based asynchronous pipelines, Spring Data which provides a ORM layer abstraction for multiple SQL, NoSQL and "Nothing to do with SQL" data stores. Spring Batch and so on. Many of these frameworks are highly evolved systems on their own that deal with a lot of small details in the big-data or enterprise development space. Many which do not have a parallel in the PHP universe, not to speak of Symfony. Not that we have not tried. And after a while of trying that you end up having the "so called PHP engineers" doing grunt work on "Plain old web applications". Whereas by switching to Java we are able to more easily leverage their skill set and give them a full set of new challenges. I cannot speak for others, but myself and everyone on our team here enjoys having a "full control of my destiny". Language is not a barrier. Unfortunately it seems that some commentators (unlike you) seem to not take away the positive aspect of the article that “Engineers are engineers, and the good ones are language agnostic and work with the appropriate tool for the job at hand”. I will also use this opportunity to comment on some of the more juvenile comments in this thread. I am a self-taught programmer (like many in the PHP community) and have only profited from the flexibility to work with the tool of choice. I would not be able to make a living writing for the Kurier, but have made a good living writing and deploying production quality code in Lisp, ActionScript, Java, Perl, PHP, Ruby, C++, Objective C and Assembly to name just a few. Thanks @Sasa for the opportunity.
Djordje
sreda, 11. Februar, 2015.
Da budem iskren ovaj tekste ne dokazuje ništa osim odluke da firma zbog njihovih razloga predje sa PHP na Javu. Pričati loše o jednom ili o drugom gubi svaki smisao. Pričati loše o razvojnim i pomoćnim alatima pisanim za javu ili php takodje gubi svaki smisao. Vaš loše iskustvo sa PHP-om koje ste opisali samo time da je java + spring bolje može da znači da vi php niste znali da koristite ili da vašim problemima više odgovaraju toj tehnologiji. Iz vašeg teksta se ne vidi konkretno zašto ste napustili php. Niste naveli probleme koje niste mogli da rešite ili koje ste sporije rešavali sa php-om. To što su vam php programeri bili produktivni za samo dva meseca ne znači mnogo. Kod mene je ekipa za dve nedelje bila produktivna na nodejs + angularjs iako su do tada radili samo javu/c# Dajte neke ozbiljne argumente i izložite probleme koje niste mogli efikasno da rešite sa php-om pa da onda nastavimo raspravu... Ovako ovaj tekst gore ima isto znacenje kao da je neko rekao "Java je bolja od php i tačka" a nema nikakav argument da to podupre... Svaka od tehnologija ima svoje prednosti i mane isto tako i programski jezici. Treba samo videti koje prednosti su ključne a koje mane se ne mogu prevazidji i na taj način odabrati. A ova dečija začikavanja su malo bzvz u današnje vreme... Ali uvek će biti pristrasnih za koje će java biti kao maternji jezik i onih za koje će php biti sve i svja...
Saša
sreda, 11. Februar, 2015.
@bal Svaka čast na pozivu na ratnu diskusiju, isprovocirali ste moj komentar. :) "Odsustvo izvanrednog frejmvorka uporedivog sa Springom smatram najvećim neuspehom PHP zajednice" - Da li možete da obrazložite zašto Symfony ne smatrate izvanrednim frejmvorkom i koje to funkcionalnosti postoje u Springu koje niste našli u Symfony-u?
bal
sreda, 11. Februar, 2015.
@Nemanja - Great contribution to the discussion.
Nemanja
sreda, 11. Februar, 2015.
Generalno ove "ratne" disksusije završe neslavno jer svaka strana ode svojoj "kući" a neko ko dođe jer zaista želi da čuje argumente ostane "kratkih" rukava. I Java i PHP su odavno izašli iz native okruženja i danas retko ko razvija aplikacije i prezentacije bez pomoći framework-a i menadžera paketa. Očigledno je i da su se kao ozbiljni kandidati za "jack of all trades" izdvojili Symfony2 (i povremeno ZF2 mada mi se čini da je utihnuo pred SF-om) sa PHP strane i Spring sa Java strane. Razlog za tako nešto je pretpostavljam što su uspeli da postanu toolbox umesto jednostavnog framework-a u koji se samo uklopiš. Problemi nastaju kod pojedinačnih problema (npr. BigData) gde jedna strana odnese prevagu nad drugom. U sferi sam web developmenta i nisam se bavio BD-om ozbiljnije te ću preskočiti da pričam o Java vs. PHP u tom segmentu. Ono gde bih želeo da dam par primera jeste web development i gde po meni nastaje glavni "raskol" PHP-a i Jave i razlog zašto sam prešao na Javu sa PHP-a. Prvi razlog je zastupljenost Jave u velikim rešenjima i zajednica koja stoji iza tih rešenja. Kada se pojavi ozbiljan problem (npr. skaliranje sistema, kontrola resursa kao što su konekcije ka bazi itd...) Java zajednica je te probleme uspešno rešila i rešenja su na dohvat ruke. Konkretan problem sa kojim sam se susreo: Producer/Consumer u distribuiranom sistemu. Sistem je bio već u PHP-u i bilo mi je potrebno da web aplikacija prosleđuje taskove za procesiranje "task" aplikaciji koja se izvršavala na nezavisnom serveru. Rešenje je bio Gearman + supervisor koji stalno "spawn"-uje nove procese (5 u datom slučaju) koji se vrte u beskonačnoj petlji poll-ujući Gearman server. Preskočiću muke sa konfiguracijom libgearman-a i PEAR ekstenzije za isti. Dakle ja konstantno imam 5 procesa (mini PHP aplikacija u CLI-u) na mašini koji konstantno RADE. Bio je tu neki sleep čisto da ne vrte baš non-stop u prazno. O sustizanju taskova i sinhronizaciji preko fajl-a neću ni da pričam. Java rešenje? Drugi projekat je u pitanju ali je rešavao sličan problem. Web aplikacija šalje task preko queue servera isto kao i PHP. Na task serveru se vrti JEDAN proces koji u while petlji proverava taskove i thread executor sa 10 thread-ova. Stigne task - prosledi se executoru i čeka novi task. Konfiguracija OS-a? 0. Brljanje sa više procesa? 0. Dokumentacija i primera na svakom koraku. Sinhronizacija? Glavni thread koji poluje queue ima potpunu kontrolu jer je to je uvek isti thread i svi resursi su tu tako da programer ima apsolutnu kontrolu koristeći samo mehanizme jezika. Ceo SF/ZF bootstrap (od index.php preko svih onih filtera pa do kontrolera i same metode za obradu) se pokreće pri svakom request-u kroz mod_php ili FPM (možda je FPM tu u prednosti zbog mogućnosti da se kontroliše broj procesa). Spring (koji kao i PHP može da ima embedovan HTTP server ali u ovom slučaju to je Tomcat/Jetty dok PHP ne pokreće ni nginx ni apache) jedan deo stvari vezan za application context inicijalizuje samo jednom (root context) dok se deo inicijalizuje za request (servlet context). PHP jeste napravio napredak sa OpCode keširanjem ali je to daleko od Java byte-code. Pros/Cons se valjda nameće sam pa nek svako izvede zaključak. I za kraj - "lakoća razvoja". Spring Boot zajedno sa Maven-om omogućavaju da kompletnu aplikaciju sa embedovanim serverom zapakujem u jedan fajl (JAR) i pokrenem ga na drugom računaru bez ikakve konfiguracije. Sva konfiguracija je u samom source code-u (sa anotacijama i aspektima čak je izbačen i web.xml i context.xml). Nemam WAMP (za Windows), nema podešavanja apache-a zbog work direktorijuma, konfiguraciju ekstenzija PHP, dal su sve uključene ili neka fali etc. Neka svako radi u čemu mu je lakše i sa čim je efikasniji. Ne postoje jezici zbog jezika nego da programeri rešavaju probleme. Koji i kad upotrebiti i kako određujte na osnovu projekta, problema i ličnih preferenci. @NekiLik - postoje dobri i loši programeri. Dobrom PHP inženjeru nije problem da radi i Javu i PHP. Sličnosti ima daleko više od razlika a domensko znanje je domensko znanje.
Zeljko
sreda, 11. Februar, 2015.
@mikica Steta sto nisi pogledao YT listu, video bi da nema potrebe za sarkazmom. Nije poenta da li ti nesto treba vec koliko ti treba vremena da bi napravio nesto komplikovano. Da ti otkrijem tajnu; taj 'super-brzi' autocomplete zahteva 6 linija koda. Image uploader kakav je na FB-u (preview slike, resize, tagovanje ljudi): 11 linija. Al ajde, uzivaj u Laravelu, neko mora i blogove da pravi :)
ВилиВулф
sreda, 11. Februar, 2015.
Ха, сад капирам. Ово није реклама за Јаву, већ за Симфони. Живео Кјек!
Mikica
utorak, 10. Februar, 2015.
@Zeljko Hvala ti puno na ovome sto si podelio sa nama, ovo je sjajno. Ja sam veoma ozbiljno shvatio ovo sto si napisao i promenio sam misljenje vezano za Laravel, slazem se u potpunosti da je za pocetnike, a da ako hocu nesto ozbiljno da pravim , da moram kao ti da koristim Symfony koji je za profesionalce. Jos uvek ne mogu da verujem kako savrseno radi ovaj super-brzi autocomplete. Fancy image uploader je toliko dobar da bez obzira sto na sajtu koji radim nema potrebe za image upload, ja sam ga ipak stavio. Hvala ti puno jos jednom, ne mogu da verujem koliko vremena si mi ustedeo, ko zna koliko bi mi vremena trebalo da sam hteo ovo da uradim sa Laravelom.
Mikica
utorak, 10. Februar, 2015.
@NekiLik Delujes mi kao neko ko sebe naziva "PHP developer", "Java developer", mozda ne bi bilo lose da procitas ovaj tekst: http://goo.gl/gPkSBK U prevodu treba da se koristi tehnologija koja je najbolja za projekat koji radis, jer jezik je samo alat i nista vise, ali ocigledno da ti to ne shvatas tako. @Zarko Sve sto moze u ZF2, Symfony2 verujem da moze i u Laravelu, ali milsim da nije u frameworku bio problem.
Zeljko
utorak, 10. Februar, 2015.
Bez uvrede ali ovo sigurno nije pisao "sjajni inzenjer" kako ste naveli; CI je odavno prevazidjen a Laravel je za pocetnike. Za bilo kakav ozbiljan posao tu je Symfony. Na primer, pogledajte ovu playlistu: http://youtu.be/G7arD0gaahM?list=PLWcgIN70RArrLsJw3qv_xr_ntvTNV3tJJ Eshop sajt, backend i frontend za samo sat vremena. I ne samo to vec se tu nalaze i fancy image uploader (kao FB) i super-brzi autocomplete koji ne trosi CPU vreme. Da nije Symfony-a, pitanje je koliko bi ovako nesto oduzelo vremena. Ukratko; mislim da se ceo clanak se zasniva na argumentu iz neznanja. PS: Izvinjavam se ali pravi email ne ostavljam na WP sajtovima
bal
utorak, 10. Februar, 2015.
In defence of PHP before the flame wars start ;-) - PHP is a very approachable language and one that can "generate income" very rapidly. As one who is a self-taught programmer whose career was kick started by another approachable language / framework ( in my case ColdFusion) I attach great value to approachability. Speaking frankly great programmers in one language will be great programmers in another. So @NekiLik is not far from the truth (if I understood correctly what he means).
Jovan
utorak, 10. Februar, 2015.
Prvo da napravim uvod: Na poslu radim Javu, na drugom poslu PHP (oba vise godina). S obzirom da sto se tice PHP-a radim u Symfony framework-u, mogu delimicno da se slozim sa ovim clankom. Ideja je da PHP i tek kako ima mane u odnosu na Javu - svako normalan moze da posvedoci, medjutim, prednosti Jave postaju ocigledne tek kada radite ultra-complex aplikaciciju koja zahteva multithreading, task scheduling itd. Za neki mid-complex aplikacije (dakle, ne pricamo ovde o "sajticima"), PHP i tek kako moze da pruzi ugodan dozivljaj tokom razvoja.
Zarko Stankovic
utorak, 10. Februar, 2015.
Definitivno ste trebali da pokusate sa Symfony2 ili ZF2. Istina je da bi bilo potrebno neko vreme da vasi inzenjeri ovladaju njima ali krajnja dobit je velika.
NekiLik
utorak, 10. Februar, 2015.
Quote : "Kada sam objavio novost učinio sam kristalno jasnim to da će svi PHP inženjeri biti glatko prebačeni na Javu." Mogu samo zamisliti kako "mocne" Java Developere imate sad ;)
Rod
utorak, 10. Februar, 2015.
Sa prva 4 pasusa sam se sa lakoćom složio. Ukratko: a) PHP treba ubiti vatrom i b) ako radite big data projekte, dobrodošli u JVM svet. Iz tog ugla, odluka je dobra. Ostalo mi nije preterano jasno, da budem iskren. Ako i dalje razvijate klasične web aplikacije, zameniti PHP s Javom je, po mom skromnom mišljenju (a na žalost i iskustvu), kao da menjate Jugo za buldožer.
Dejan
utorak, 10. Februar, 2015.
BIlo koji programski jezik gazi PHP uveliko (dobro, mozda ne Basic :D ). Jednostavno ne moze ispuniti zahteve koje postavljaju danasnje aplikacije.
bal
utorak, 10. Februar, 2015.
We did do a round of checks on Zend and Symphony before we went from CodeIgniter to Laravel. And the decision was based on feedback from the internal developers who had worked with both. We actually also worked with the Slim Framework ( http://www.slimframework.com/ ) which in the end proved to be a bit anorexic for our use case. You can also do very lightweight stuff with Spring where it looks more like Jersey ( Like the Spring Boot REST ) package. Either way, this article definitely needs to be seen in the context of big-data and the emerging event-driven-architectures where any framework / language mix would find it challenging against Spring / Java.
Alex
utorak, 10. Februar, 2015.
"Spring je ispred Laravela ili CodeIgnitera" - ispred CodeIgnitera je svaki FW, njega cu cak i kreatori napustili, a Laravel je previse light i to je njegova filozifija. Da li ste pokusali sa nekim ozbiljnijim PHP frameworcima poput ZF2 ili Symfony koji imaju arhitekturu za enterprice projekte ? I koje je Vase poredjenje u odnosu na Springa FW?