Pakettien hallinta bowerilla?

[ioxo]

Terve,

Tässä kattelin pitkästä aikaa sorsia ja huomasin, että siellä täällä hakemistoja on läjä "vieraita" komponentteja eli siis jquery, jquery-ui, datejs, datatables, md5, select2 jne.

Mieleeni tuli, että jos kaikki nuo keräis yhteen paikkaan/yhden hakemiston alle ja hommaa hoitais bower-pakettien hallinta. Järjestelmää olisi myös myöhemmin helppo päivittää, jos jokin komponenteistä päivittyy niin kehityspuussa (komentotulkissa) voisi vain komentaa "bower update". En tiedä mitä muut kehittäjät käyttävät, mutta itselläni on Linux ja bower sun muut kumppanit asentuu mukavasti. Löytynee myös Windowsille.

Jos bower ei ole tuttu, niin sillä pystyy hakemaan netistä kaikkia suosittuja javascript-pluginejä / css-frameworkejä jne. Bower tekee oletuksena bower_components hakemiston, johon se kopioi kaiken tarvittavan. Esim. "bower install jquery" tekee hakemiston bower_components/jquery/..." ja lataa kaiken tarvittavan. Useissa bowerin paketeissa on dist, build, production tai vastaava hakemisto, josta löytyy minified-versiot valmiina.

Jotta homma menis tietämättömälle vielä haastavammaksi tein grunt:lla kokeiluversion, joka noukkii tuolta bower_components hakemistosta MLInvoicelle tärkeitä paketteja ja kopioi ne dist/ hakemiston alle. Tässä on/olisi se pointti, että kun githubista saa noudettua lähdekoodin niin bower_components hakemiston voi pitää tyhjänä. dist/ hakemistossa olisi bower_components/ hakemistosta noudettuna tarvittavat tiedostot ja jos joku haluaa muuttaa noita valmiita komponentteja niin voi päähakemistossa komentaa "bower install" ja kaikki ulkopuoliset komponentit haetaan koneelle.

Bower ja grunt on riippuvaisia node.js:stä. Kun koneelle on asennettu node ja npm (node package manager), niin homman saa käyntiin kopsaamalla package.json, bower.json ja .bowerrc tiedoston koneelle ja komentamalla (samassa hakemistossa) npm install [enter], bower install [enter], grunt [enter].

Homman vaikeushan on sitte siinä, että koko koodi pitää kirjoittaa <element src=""> osalta uusiksi eli kaikki src:t jotka viittaa js/css tiedostoihin niin tarvitsee uuden kohteen.

Mitä mieltä olette tämmöisestä uudistuksesta?

- Juho

[Ere Maijala]

Ihan hauska idea, mutta en kyllä ajatellut lisätä riippuvuutta Node.js:stä kehitystyökaluihin. Toinen juttu on sitten se, että seuraava iso askel olisi kirjoittaa homma uusiksi jollain fiksulla frameworkilla, ja sen valinta vaikuttanee myös komponenttien sijoitteluun tai asennustapaan...

--Ere

[ioxo]

Hee, niinpä niin. Itsellä kun on kaikki mahdollinen melkeinpä asennettuna ;) niin ei tullut ajatelleeksi tuota näkökulmaa, että sehän tosiaan luo lisäriippuvuuden. Tosin tuossa riippuvuutta ei ole pakko käyttää ja kehitystä voi silti jatkaa ilman, että joutuisi asentamaan koko nodea (paitsi pääkehittäjän, joka pitää paketin kasassa) ... Suurin osa paketeistahan on semmoisia, joihin ei kosketa sen lataamisen jälkeen kuten vaikka jquery.

Oletko Ere tutustunut Laravel frameworkkiin? Näyttää joksenki selkokieliseltä =). Kannattanee valita suht helpohko framework, jotta mahdollisimman moni osaa lukea ja jokunen kirjoittaakin :).

-Juho

[Ere Maijala]

Juu, Lavarel on ihan vahva kandidaatti. Vieläkään en ole kuitenkaan saanut päätettyä asiaa...

--Ere

[ioxo]

Mulla on nää kehitysehdotukset aina hyvän otsikon alla... nojoo ;)

Pääidea mun mielestä kannattaa pitää tuossa, että oli mikä oli frameworki niin mahdollisimman simppeli luettavuudeltaan. Auttaa kehitystä monilta osin. Ne jotka osaa ontuvasti koodata ja ne jotka osaa koodata hyvin, molemmat koodaajat voivat lähettää ehdotuksia jostain kohdasta / featuresta / bugista.

Yritän myös vähän ajaa takaa että php ja javascript ovat samankaltaisia ohjelmointikieliä (joskin suurilla eroavaisuuksilla), mutta joissain kohtaa se yksi if-lausekkeen rakenne voi ratkaista ison ongelman - ja taas if-lauseke on javascriptissä ja php:ssä melkeinpä 1:1.

Toinen/kolmas juttu mitä oon miettiny, niin ois varmaan fiksua käyttää laskutusohjelman frontendissä jotain AngularJS tyyppistä ratkaisua. Tällä tavoin sais ohjelman logiikkaa vietyä selaimelle ja javascriptin upottaminen on huomattavasit järkevämpää kuin miljoonien $('element') härpäkkeiden luominen jqueryn avulla.

Jostain syystä myös hyvä modulaarisuus pyörii kovasti kehitysideassa. Tietyllä tapaa toteuttelis erp:n kaltaista systeemiä, mutta toteutetaan pelkkä pohja ja laskutus (moduulina), asiakasrekisteri (moduulina) ja varasto/tuottet (moduuli). Tällöin voisi paremmin saavuttaa lontoota puhuvaa yleisöä ja saada ohjelmalle nostetta... tai sitten ei. Ja esim. käännökset vois organisoida transifexin kautta (www.transifex.com).

Laskutukseen vois taas sit tehdä jotain pluginejä että "tulosta pdf", "tallenna pdf gdriveen", "tallenna pdf owncloudiin", "tallenna pdf dropboxiin", "tulosta käyttäen postin nettipalveluja" jne.

Asiakasrekisteriin vois taas sit tehdä jotain pluginejä että "iCard (google contacts, applen ohjelmat)", "owncloud integroiminen" jne

Tavallaan koko ohjelmassa ois pohja noille moduuleille ja plugineille, että osaava ohjelmoija vois halutessaan helposti koodata plugarin/moduulin kiinni koko järjestelmään. Ideana siis vain, että hyvin suunniteltu pohja luo hyvät edellytykset ohjelman kehittymiselle, ylläpitämiselle, kasvamiselle yms.

Nää on sitte ajatuksia eikä mitään ehdottomia vaatimuksia :D. Toivottavasti joku komppaa tai ehdottaa jotain lisää/muuta...

-Juho

[Ere Maijala]

Taitaa Laravel nyt tippua ehdokkaiden joukosta. Vaikka se vaikuttaa muuten mielenkiintoiselta, ei se näytä soveltuvan softaan, joka pitäisi saada helposti asennettua jaettuun hostauspalveluun vailla shell-oikeuksia ja ilman sen suurempaa teknistä osaamista. Katsellaanpa muita.. Näyttää näillä kriteereillä monikin framework tippuvan pelistä, kun ne on suunniteltu tavallaan sisäiseen käyttöön, jossa oletetaan, että on kehitysympäristö, testausympäristö ja tuotantoympäristö eikä paljon muuta. Kuitenkin esim. Yii:n kohdalla löytyy myös valmiiksi hostaukseen sovitettu versio.

Ehkä Laravelin kanssakin voisi virittää homman toimimaan, mutta en usko, että se on järkevää, jos ei softaa ole siihen tarkoitettu. Joka tapauksessa asennuksen yhteydessä ei voi vaatia composerin käyttöä tai pääsyä komentoriville ajamaan migraatioita. Tokikaan ei haittaa, jos näitä voi käyttää kehityksessä apuna.

--Ere

[ioxo]

Hei,

Aa... totta. Tuota jaettua hostauspalvelua en tullutkaan ajatelleeksi.

Kehityksen kannalta mielestäni laravel on aika selkeä framework. Tuostahan saa nettitietojen perusteella tehtyä jaettuun hostaukseen soveltuvankin version - tosiaan ne muutokset myös pitää tehdä eikä onnistu heittämällä "on-the-fly". Mutta onko paha muutos, jos joka tapauksessa täytyy tehdä julkaisuversioihin täydellinen versio [zip] (jos käytetään composeria tai muita työkaluja)? jos katsoin oikein niin kahteen php-tiedostoon piti muuttaa muuttujia ja nämä tiedostot tulee olemaan koko projektin ajan samoina (?)

Laravelissä mun mielestä on helppoa se, että sitä pystyy käyttämään myös ilman apachen / nginxin asentamista käyttäen artisan scriptiä ("artisan serve").

Composerista en näe kuin positiivista. Git:ssä voi jakaa pienintä mahdollista versiota ja jokainen sorsan lataaja/tutkailija voi komentaa "composer install". Ne joilla ei ole composerin käyttömahdollisuutta / ei halua tutkia koodia voi ladata jonkin "stable-release.zip"-version, joka sisältää kaiken olennaisen. Tuon pakettihallinnan avulla pysyy hyvässä ryhdissä kaikki select2, date/momentjs, tcpdf jne toiminnot kasassa, jos jostakin tulee uutta versiota se voidaan myös kätevästi päivittää. Tosin githubissa voi nyt pitää koko sorsapuuta jaettavana vaikka tulisi kuinka monesta composer paikasta :).

Mielestäni kovin marginaalista frameworkia ei kannatane ottaa käyttöön (http://www.sitepoint.com/best-php-frameworks-2014/). Yii nyt on aika tunnettu, mutta omasta mielestäni huomattavasti sekavamman oloinen kuin laravel. Codeigniter oli yhessä projektissa ja se oli aika simppeli. En tosin tiedä onko se nyt kuolemassa vai ei, toimii hostatussa palvelussa "on-the-fly".

Mielellään osallistun kehitykseen sen minkä osaan ja kykenen. Nykyisessä on mvc-rakenne hiukan hakusessa ja sen patchaaminen on aika tuskallista... (ei pahalla).

-Juho

[Ere Maijala]

Testasin vähän Yii2-pohjaista softaa, ja täytyy todeta, että ei nyt ihan tunnissa tullut valmista. Tutkailen siis vielä myös tuota Laravelin sovittamista hostaukseen. Ei siinä paketointi ole ongelma, vaan se, että esim. asennushakemiston vaihtaminen www-serverin root-hakemistosta johonkin muualle vaatii puukottamista ties miten moneen kohtaan. Sellainen ei käy softassa, joka pitää saada asennettua ilman koodauskokemusta. Pitää siis saada aikaan systeemi, joka ei välitä siitä, onko se asennettu juurihakemistoon tai johonkin alihakemistoon tai vielä syvemmälle. Eikä saa vaatia esim. artisan-komennon ajamista komentoriviltä.

Muuten siis composer ilman muuta..

Mitä nykyisen softan rakenteeseen tulee, niin siinä varmaan oli ihan hyvä idea alkuun, kun toiminnallisuus oli tosi simppeliä. Ei siis mikään MVC-rakenne, mutta ei sellainen ihan simppelissä softassa olekaan välttämätön. Joka tapauksessa minähän sitä aloin kehittää tuosta eteenpäin sen enempää rakennetta kehittämättä, joten oma vika tietenkin tuo suo, jossa nyt lillutaan. Ei siis ole täällä päässä mitenkään epäselvää, miten sekava tuo rakenne nykyään on.

--Ere

[ioxo]

Puhut asiaa.

Itse olen aina laittanut subdomainin alle, teknisesti orjentoitunut enkä osannut ottaa huomioon alihakemisto-ongelmaa.

Itse näkisin myös että joitain kompromisseja kannattaa asioiden suhteen tehdä, jos joku ei osaa laittaa palvelua itselleen (vaikka localhostiin tai virtuaalikonetta), niin myydäänkö sitten palvelua, jossa kyseinen homma voitaisiin suorittaa? esim. asiakas1.labs.fi ? asennus ilman varmuuskopiointia x,xx e/kk tai sen kanssa n,nn e/kk? Tietty jos löytyy mukava frameworkki jolla homma onnistuu helposti alihakemistojenkin kanssa niin mikä ettei.

Uskon, että asiaan perehtyneellä tuo sorsien muokkaaminen ei ole se kaikista vaikein, mutta kun tämmöinen sivutoiminen koodari yrittää saada tolkkua asiaan, niin... no mielummin kattelis sitä view-osiota, johon on enemmän niitä visioita :).

Nykyinen kyllä kattaa kivasti ominaisuuksia laskutukseen liittyen, mutta siihen asioiden lisääminen ja muokkaaminen on vain vaikeaa.

-Juho

[Ere Maijala]

Tokihan palvelun tarjoaminenkin on mahdollista, tosin siihen en ole vielä itse ryhtynyt, koska siihen liittyy kaikenlaisia tuki-, palvelutaso- ym. lupaukset, päivitysten tekeminen jonkin sovitun huoltoikkunan aikana, tietoturvavastuut ja kaikenlaista muuta mukavaa. Siksi haluan pitää softan sellaisena, että periaatteessa kuka vain saa sen asennettua ohjeiden avulla esim. XAMPP:n päälle omassa Windows-koneessa.

Helpottaahan se toki myös kehitystyötä, ettei softan asentaminen johonkin hakemistoon vaadi paljon muutoksia, koska voi olla tarpeen pitää monta versiota rinnakkain, eikä ole kauhean kätevää aina laittaa jokaiselle omaa alidomainia. Alidomaineissa on sekin ikävyys, että ainakin osassa www-hotelleista niistä joutuu maksamaan ekstraa.

--Ere

[ioxo]

En tiedä mitä kaikkea joutuu tekemään palveluntarjoajana ja mistä kaikesta pääsee irti vastuusta kun kertoo sopimusehdoissa asiasta (yksinkertaistettuna tms), kysehän on kumminkin yrityskaupasta jossa ei tarvitse ottaa huomioon kuluttajalakia (joka rajoittaa toimintaa monessa suunnassa). Mutta vastuutahan siinä on helposti enemmän kuin nykyisessä systeemissä, joka on moneen suuntaan simppeli. Järjestelmän kannalta vois olla myös hyvä että varmuuskopiot dumpataan palvelimella johonkin hakemistoon (automaattisesti aina (avointa) laskua luodessa), jossa ne on sitten

• backup/invoices/2015/01/lasku_001.pdf
• backup/invoices/2015/01/drafts/draft_002.tmpl (jonkin sortin template, josta pystyy parsimaan tietoja? ja draft muuttuisi pdf:ksi kun siitä tulisi lasku)
• backup/contacts/client1.ical,csv (tms tiedostomuoto)

Jos systeemi kosahtaa ja hajoaa käyttökelvottomaksi, niin nuo saisi poimittua sftp/ftp:llä talteen - ja muutenkin varmuuskopiointi olisi suhteellisen helppo toteuttaa ties minkälaisilla python/ftp/sftp/rsync virityksillä.

Tämmöisen jälkeen 'tee varmuuskopio' olisi melkeinpä turha nappi...  (mutta ei kumminkaan, jos miettii että sieltä saa sql-scheman) :). Napille voisi keksiä myös uusia alifunktioita kuten pakkaa zipiksi kyseiset filut (compression 0, niin niputtaisi kivasti - ei söisi palvelintehoa)

En tiedä miten webhotelleissa pääsee  rustailemaan htaccess tietoja ja muita rewrite-sääntöjä. Luulenpa, että niillä saisi nuo frameworkkien harrastamat / -osoitteet muotoon /mlinvoice/ muotoon.

Nykyään tuppaa olemaan vain aika helposti nuo frameworkit tuommoisia, jotka "valtaa" koko serveri hakemistorakenteen itselleen. XAMPP ympäristössä voi olla helpompi systeemi, jonka voi heittää hakemistoon kuin hakemistoon. Useat framworkithän ei tarvi edes välttämättä palvelinta toimiakseen vaan toimii php:llä itsessään. Mutta samapa kai se mikä frameworkki on käytössä, kunhan on sinut sen kanssa ja on suhteellisen tehokas.

-Juho

[Ere Maijala]

Hitaasti hyvä tulee, joten sillä lailla tämä on edennyt. Päädyin nyt yrittämään Laravelin kanssa. Voi sitten tuota hostaukseen sovittamista miettiä, kun kaikki muu on valmista. 8) Vielä pitää pohtia, tulisiko fronttipuolelle jotain perinteikästä tyyliin html/bootstrap/jquery vai kenties AngularJS-pohjaista modernimpaa ratkaisua.

--Ere

[ioxo]

Mahtavaa!

Harmittaa itseä kun ei ole niin hyvä koodaaja että osaisi kokonaista pakettia tehdä kasaan vaan enemmän osaan tehdä vain pieniä ehdotuksia/muunnelmia :(.

Uskon, että itse kullekin on helpompaa seurata/muokata koodia jos se on hiukan jäsennelty / modularisoitu.

Olen samaa mieltä hostauksesta, jos ei halua ulkopuoliselle maksaa hostauksesta, jolla homma onistuisi niin mikä estää laittamasta omaa xamp ympäristöä pystyyn tai kyllähän tuo varmaan pyörii rasberry pi:läkin jos haluaa homman "ulkoistaa" :). Btw, nykyinen toimii hyvin nginx ympäristössäkin.