Citat:
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.
Citat:
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.
Citat:
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.
Kod:
→ 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)
Citat:
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.
Citat:
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
Citat:
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.
Citat:
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.
Citat:
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?
Citat:
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