[hnn]

Jag tror du vill ha PEAR eller PECL

http://pear.php.net
http://pecl.php.net

[Nerix]

Ursprungligen postat av hnn

Jag tror du vill ha PEAR eller PECL

http://pear.php.net
http://pecl.php.net

Med tanke på hur stort PHP är så borde man tycka att dom skrapat ihop mer än 800 (!) paket.

Någon som har nått alternativ, eller är det så här de ser ut?

[abergman]

Ursprungligen postat av Nerix

Med tanke på hur stort PHP är så borde man tycka att dom skrapat ihop mer än 800 (!) paket.

Någon som har nått alternativ, eller är det så här de ser ut?

Men vilka funktioner i paketen är det du är ute efter?

Kolla på php.net så ser du vilka funktioner som existerar, och sen får du googla lite klasser om det är funktioner du vill ha som inte redan finns.

[Clarence]

Ursprungligen postat av Nerix

Med tanke på hur stort PHP är så borde man tycka att dom skrapat ihop mer än 800 (!) paket.

Någon som har nått alternativ, eller är det så här de ser ut?

Om du vill ha någon pakethanterare så är det så det ser ut. Nöjer du dig däremot med att ta 1 manuell minut per projekt har du betydligt fler bibliotek tillgängliga än i de flesta andra språk.

[Nerix]

Ursprungligen postat av abergman

Men vilka funktioner i paketen är det du är ute efter?

Jag hade tänkt mig något likt Rubygems.org

Drygt 22k plugins.

Att uppfinna hjulet på nytt för varje gång känns ju aningen getto.
Sedan så saknar jag expertis inom varje område, så att överlämna arbete till 3:e part är något jag gör med glädje.

Ursprungligen postat av abergman

Kolla på php.net så ser du vilka funktioner som existerar, och sen får du googla lite klasser om det är funktioner du vill ha som inte redan finns.

Vi har nog lite olika krav på koden som ska användas i produktion.
Ett plugin ska, enligt mig, var testad, dokumenterad, ligger under en vettig licens och vara distribuerad via ett ordentligt nätverk.

Ett kodstycke skrivet av en nybörjare utan tester postat på ett forum ligger inte under den kategorin.

Ursprungligen postat av Clarence

Nöjer du dig däremot med att ta 1 manuell minut per projekt har du betydligt fler bibliotek tillgängliga än i de flesta andra språk.

En minut per projekt, vilket enligt koden jag nyss postade är 190 minuter, och det är varje gång jag ska kolla efter uppdateringar.

I min värld går detta via ett kommando på drygt 5 sekunder.

Jag ger språket 24h till, sedan drar jag mig tillbaka.

[Clarence]

Ursprungligen postat av Nerix

En minut per projekt, vilket enligt koden jag nyss postade är 190 minuter, och det är varje gång jag ska kolla efter uppdateringar.

I min värld går detta via ett kommando på drygt 5 sekunder.

Jag ger språket 24h till, sedan drar jag mig tillbaka.

Det där verkar ju enbart bygga på desinformation. 80% av det du drar ner gems för är inbyggt i PHP, 10% till finns i via apt-get eller pecl (här ligger t ex phpunit och oauth). Återstående procent är något man ändå för det mesta får se till att underhålla själv om man vill uppgradera. Ett väldigt enkelt exempel är Jquery som kan ha sönder din kod genom automatisk uppgradering då den inte alltid är bakåtkompatibel.

Sen är det, oavsett vilka språk man vill byta mellan, vissa saker som görs sämre eller inte alls i ett nytt språk. Är man inte öppen för det och ger det en extra dag när man möter motgångar så är det nog bättre att bara hålla sig på den trygga sidan språkbarriären.

[Nerix]

Ursprungligen postat av Jine

Sätt upp en egen apt-get repo?

Hur är det tänkt att jag ska använda apt-get under OS X?

Rubygems är plattformsoberoende.

Ursprungligen postat av Jine

Saken är väl den att PHP har mycket inbyggt direkt.
Du behöver inte hämta gem's för t.ex. json, mysql, sqlite osv.

Att MySQL ligger som en egen gem i stället för att vara inbyggd i core-delen betyder att utvecklingen kan ske parallellt med språket.

Jag har själv varit med och skrivit patchar för mongodb. Ändringarna kördes in i stable på mindre än 1 vecka.
Skulle mongodb eller mysql i stället varit native så skulle patchen förmodligen inte mergas in förrän nästa version, vilket när det kommer till Ruby och PHP tar sin lilla tid.

Ursprungligen postat av Jine

Om du saknar något i PHP, säg gärna till. Jag har inte hittat någon direkt saknad support på ett par år.

beanstalk-client - Bryggan mellan beanstalkd och Ruby.
whenever - Möjliggör crontasks direkt från Ruby.
Capistano - Deploy-verktyg
eventmachine - Eventhantering i Ruby
undertexter - Inofficiellt API för undertexter.se
spotify - Spotify-klient
Hallon - Bryggan mellan libspotify och Ruby.
haml- Ett alternativ till rent HTML
BSON - Den binära version av JSON

Det jag menar är att jag kan hitta allt och lite till, full dokumenterat, med tester som kräver att jag varken kopierar någon kod eller bryter mot några skumma, möjligen icke existerande licensavtal.

Skulle paketet vara utdaterat och finns på Github (vilket många utav paketen gör) så kan jag utan några konstigheter göra forka projektet, fixa felet, göra en pull-request var vid ägaren (förhoppninsgvis) mergar in min ändring. Vart efter paketet pushas upp till rubygems och finns tillgängligt för allmänheten.

En viktig del är även att jag får cred för patchen jag skrev, något som både Rubygems och Github fixar.

Lätt som en plätt.

Sedan kanske det är värt att nämna att siter som Github ökar överlevnaden för ett projekt. Jag har sedan drygt ett år tillbaka valt att publicera alla smådelar för mina projekt som egna gems. Små finesser som byggt efter alla konstens alla regler. Jag kan där efter publicera paketet och låta OSS-comunity:t vidareutvecklare projektet.

Jag menar; chansen att fler söker efter lösningar på samma problem som jag är ganska stor. Finns det fler användare så finns det även fler utvecklare som kan jobbare vidare på projektet.

Jag tror att det jag saknar mest är implementeringen av alla dessa API:er.
Om man te.x får för sig att skriva en site som jobbar mot eBay så kan man ge sig f*n på att någon redan har skrivit en gem.

Plockade bara något ur skjortärmen, har ingen aning om träffarna är någon att ha.

→ gem search -r ebay

*** REMOTE GEMS ***

ctagg-ebay_shopping (0.1.1)
ebay (1.1)
ebay-finder (0.1.3)
ebayapi (0.12.0)
garrytan-ebayapi (0.12.2)
handcrafted-ebay_products (0.1.2)
lukebayes-clix_flash_player (0.3.0)
rebay (1.1.2)

Ursprungligen postat av Jine

OAuth osv, laddas ner som php-klasser med vettig licens, dokumentation och exempel, behövs inga moduler för det.

Yeah, du hittade en. ~ 22k kvar.

Själv använder jag OmniAuth.
Stöd för auktorisering mot ett 30-tal siter.
Implementeras med ett fåtal rader kod.

Ursprungligen postat av Jine

Det svåra i att skapa ett sånt här verktyg är att du isåfall behöver utgå ifrån en förutbestämd katalogstruktur, då PHP är så fritt finns det inga direkta verktyg för att göra det.

Nja. Mappstrukturen kan se ut hur som helst, så länge man lägger till projektet i load-pathen.

Paket som jag installerar lägger sig i en dold-mapp i min hem-katalog.
Exakt hur projektet är uppbyggt behöver jag aldrig bry mig om.

För att distribuera en s.k gem så används en gemspec-fil där namnet på författaren angivits och även vart huvud-filerna ligger.

Här är ett exempel

Ursprungligen postat av abergman

Jag kan bara hålla med här, i princip alla grundstenar som behövs finns reda i PHP, sedan får man som utvecklare bygga det mesta själv

Hur hittar ni (PHP-utvecklare) kunder som kan tänkas betala för det här?
Utvecklingstiden måste ju vara flera gånger vad det skulle tagit att implementera samma funktionalitet i Python, Ruby eller exempelvis Haskell.

Ursprungligen postat av Magnus_A

Verkar som det är ett ramverk du efterfrågar, till exempel Zend Framework som har färdiga bibliotek och funktioner för det mesta du kan tänka dig. Fördelen med Zend är att du har tillgång till biblioteken fullt ut utan att behöva hoppa på Zend Frameworks sätt att implementera MVC.

Jag tivlar på att Zend Framework har inbyggt stöd för brittiska polisens API.

Ursprungligen postat av Clarence

Det där verkar ju enbart bygga på desinformation. 80% av det du drar ner gems för är inbyggt i PHP, 10% till finns i via apt-get eller pecl (här ligger t ex phpunit och oauth).

Listar paketberoenden längre ner. (Hehe, inlägget blev för långt, kan ta och posta listan i ett inlägg till om det är så att du är intresserad.)
Enligt en kompis till mig så innehåller listan knappt 2% standardbibliotek. (4 av 194)

json, mysql, sqlite3, xml-simple

Var av json-paket inte längre behövs i Ruby 1.9.

Sedan så förstår jag inte riktigt hur jag ska få api-get att fungera under något annat än Linux.
Hur gör jag i OS X, eller Windows om jag väljer att sätta mig där?

Ursprungligen postat av Clarence

Återstående procent är något man ändå för det mesta får se till att underhålla själv om man vill uppgradera. Ett väldigt enkelt exempel är Jquery som kan ha sönder din kod genom automatisk uppgradering då den inte alltid är bakåtkompatibel.

Det är därför man låser paket-beroenden. Man specificerar helt enkelt vilka version av ett paket som får installeras.

Själv så kör jag dock alltid på de nyaste versionerna, skulle testerna för applikationen inte gå igenom efter en uppdatering så ser jag till och fixa felet bara.

@alla
Det skulle vara väldigt intressant och se hur ni själva bidragit till ert community.
Hur publicerar ni er kod om ingen hittar den te.x?

Jag har själv ett 70-tal OSS-projekt igång med dryga 6000 nedladdningar på Rubygems de senaste månaderna.

Intressant diskussion f.ö, jag hoppas inte att ni tar det allt för personligt

[Clarence]

Ursprungligen postat av Nerix

Att MySQL ligger som en egen gem i stället för att vara inbyggd i core-delen betyder att utvecklingen kan ske parallellt med språket.

Borde då inte core vara fritt från allt? Jämförelsevis ligger dock mysql som extension till php (pecl install pdo_mysql - done).

Jag har själv varit med och skrivit patchar för mongodb. Ändringarna kördes in i stable på mindre än 1 vecka.
Skulle mongodb eller mysql i stället varit native så skulle patchen förmodligen inte mergas in förrän nästa version, vilket när det kommer till Ruby och PHP tar sin lilla tid.

Pecl install mongo

Det jag menar är att jag kan hitta allt och lite till, full dokumenterat, med tester som kräver att jag varken kopierar någon kod eller bryter mot några skumma, möjligen icke existerande licensavtal.

Skulle paketet vara utdaterat och finns på Github (vilket många utav paketen gör) så kan jag utan några konstigheter göra forka projektet, fixa felet, göra en pull-request var vid ägaren (förhoppninsgvis) mergar in min ändring. Vart efter paketet pushas upp till rubygems och finns tillgängligt för allmänheten.

En viktig del är även att jag får cred för patchen jag skrev, något som både Rubygems och Github fixar.

Lätt som en plätt.

Det finns 2 skillnader mot PHP här. Rubygems finns inte för automatiska uppdateringar osv och det finns BETYDLIGT mer bibliotek till PHP. Nej, allt som finns i Ruby finns inte i PHP. Det går dock åt båda hållen. Och detta gäller precis oavsett vilka 2 språk du går imellan.

Sedan kanske det är värt att nämna att siter som Github ökar överlevnaden för ett projekt. Jag har sedan drygt ett år tillbaka valt att publicera alla smådelar för mina projekt som egna gems. Små finesser som byggt efter alla konstens alla regler. Jag kan där efter publicera paketet och låta OSS-comunity:t vidareutvecklare projektet.

Jag tycker detta är riktigt bra. Det är ett område där ruby-utvecklare är mycket bättre. Med en bråkdel av utvecklarna så är antalet projekt för ruby på github drygt dubbelt så många som för php. I mångt och mycket tror jag det handlar om fördelen med en kultur som växt från början - snarare än kommit efteråt. När PHP blev gigantiskt fanns inte github eller mostvarande tjänster. Ruby har växt till sig starkast i samma era som motsvarande tjänster.

Jag menar; chansen att fler söker efter lösningar på samma problem som jag är ganska stor. Finns det fler användare så finns det även fler utvecklare som kan jobbare vidare på projektet.

Jag tror att det jag saknar mest är implementeringen av alla dessa API:er.
Om man te.x får för sig att skriva en site som jobbar mot eBay så kan man ge sig f*n på att någon redan har skrivit en gem.

Det är här du är fel ute. Bara för att det inte finns en centraliserad källa som har allt innebär det inte att vem som helst på en minut kan finna sådana saker. Skillnaden är att du får känna till ett par tre sajter eller göra en google-sökning

Själv använder jag OmniAuth. Stöd för auktorisering mot ett 30-tal siter. Implementeras med ett fåtal rader kod.

Jag tror detta kan tas som ett exempel på att du aldrig finner exakt samma motsvarigheter i olika språk. Att hitta slimmade bibliotek för respektive inloggning är lätt för PHP. Men ett samlat bibliotek för alla vet jag inte om det finns.

Hur hittar ni (PHP-utvecklare) kunder som kan tänkas betala för det här?
Utvecklingstiden måste ju vara flera gånger vad det skulle tagit att implementera samma funktionalitet i Python, Ruby eller exempelvis Haskell.

Nej. PHP-utveckling är generellt sätt både billigare och lättare att finna utvecklare för än python, ruby och haskell. Utvecklingstiden har du fått om bakfoten då du verkar tro att precis allting skrivs från scratch. Det används ofta/för det mesta ramverk, bibliotek, specialiserade plugins osv samtidigt som du har väldigt väldigt mycket inbyggt i språket så att du får mer standardiserad utveckling.

Jag tivlar på att Zend Framework har inbyggt stöd för brittiska polisens API.

Om nu obskyr kod som ingen använder skulle vara av värde kan jag försäkra dig om att det finns gott om det för PHP också.

json, mysql, sqlite3, xml-simple

Samtliga är med i en standard PHP-installation. Skulle du inte ha kompilerat med t ex mysql får du in den senaste genom en pecl install mysql

Sedan så förstår jag inte riktigt hur jag ska få api-get att fungera under något annat än Linux.
Hur gör jag i OS X, eller Windows om jag väljer att sätta mig där?

Nej under de plattformarna får du nog nöja dig med en checkout från subversion/git efter en google-sökning.

Det är därför man låser paket-beroenden. Man specificerar helt enkelt vilka version av ett paket som får installeras.

Låser man paketversionerna så blir man väl av med största nyttan av detta sätt att föra in funktioner? För mig är iallafall den enskilda ordentliga nyttan att du faktiskt kan uppdatera mjukvaran i ett steg. Men då har du såklart nackdelen med alla community-kod att du ofta inte har en aning om hur stabil den är. Prestanda-problem kan exempelvis smyga sig in utan att upptäckas i tester - och i sin tur slå ner hela systemet.

Jag är inte ute efter att övertyga dig om att PHP är bättre. Däremot så tycker jag att hela din insats i att ge dig på PHP verkar baseras på att allt ska fungera precis likadant som det språk du förälskat dig i. Om man inte kan överge det till en början tror jag inte det är någon större poäng med att försöka utöka sin värld med fler språk.