One More Thing » Community » Forum » Pro » Software-ontwikkeling » Programmeren – compiler – Ruby, YAML – static site?

Programmeren – compiler – Ruby, YAML – static site?

Profielfoto van Shmoo

Shmoo op 08 augustus 2017 #

Ik geef toe, dit is een vreselijk lelijke titel voor een nieuw topic maar ik kon even geen betere allesomvattende titel bedenken voor waar ik naar op zoek ben.

De afgelopen tijd ben ik druk-druk bezig geweest met van alles en nog wat en heb ik een aantal dingen geprobeerd. Eén daarvan is mijn teentjes gedipt in het water dat iOS development heet. Omdat ik mijn teentjes lief heb en ik deze in de toekomst nog vaak wil laten wiebelen ben ik na een weekje stoeien gekapt want dat is alles behalve COOL en voor mij.

Voor mijn gevoel leven de vroegere web development jongens en meisjes op dit moment in de beste tijd van hun leven. Er is zo verschrikkelijk veel gaande op dit moment wanneer je nieuwe dingen wilt leren. Je kunt allerlei kanten op en geweldige systemen ontdekken, Web Apps, API’s, Frameworks, Style-guides, al het SVG gebeuren en ga zo maar door. Je zou waarschijnlijk van gekkigheid niet weten waar je je in wilt verdiepen.

Iets dat mij al jaren kriebelt zijn de Static Site generators. Ik weet dat er heel erg veel over gesproken wordt en veel moet je met een korreltje zout nemen want mensen vinden tegenwoordig vaak al heel snel iets geweldig wanneer het HUN persoonlijk goed uitkomt voor één project.

Waar ik naar toe wil is eigenlijk het volgende. De Static HTML generators zijn al een tijdje aanwezig maar ik heb nog steeds niet het idee dat dit de volgende WordPress is. Iets dat serieus kan groeien en extreem populair kan worden. Ik heb het idee dat het allemaal blijft steken op een X niveau en dat niveau is vooral HTML sites waar echt en alleen maar gewerkt wordt met static ‘pages’ toevoegen. Zodra je wilt gaan ‘bloggen’ of iets van een nieuws systeem met categorieën en een klein beetje dynamische content wilt gaan koppelen dan worden deze static generators ineens meteen ingewikkeld en van het niveau schoonmoeders. Ontwijken!

En ja er zijn voorbeelden zat van mensen die online schreeuwen dat ze WordPress hebben verlaten voor Jekyll maar wat je dan krijgt te zien is hun persoonlijke blog of portfolio met 5 pagina’s en wat ze vooral geweldig vinden is dat ze alles doen vanuit een Markdown file. Dat heeft natuurlijk nergens iets mee te maken.

Nu heb ik heb ik vorige week een cursus gevolgd over Jekyll ik moet zeggen wanneer je eenvoudig wat ‘about’, ‘contact’ en al dat soort pagina’ wilt pushen naar een server is dit idd. extreem sexy. Maar zodra je iets van categorieën of tags wilt koppelen dan wordt het bouwen ineens het lelijkste dat je ooit gezien hebt.
Voorbeeldje.
https://www.dropbox.com/s/isq3xzhff3e8u1z/Liquid_haha.mp4?dl=0

Niemand hier kan mij toch vertellen dat wat je hierboven in dit *filmpje ziet gebeuren dat zoiets het antwoord zou zijn op wat men noemt ‘performance winst’ tegenover systemen zoals WordPress.
*Voordat je dit filmpje bekijkt. Laat je vrouw/vriendin eerst alle vorken in het huis verstoppen want de kans is aanwezig dat je na het kijken van dit filmpje je eigen ogen wilt uitprikken.

Om een lange vraag korter te maken aan mensen die weten hoe programmeren werkt en doe computers bestanden compilen en wat daar vooral voor nodig is.
Ik wil extreem graag overzetten op een static site generator maar dat moet er wel een eenvoudigere manier zijn om een blog systeem toe te voegen.  Dus bestanden die in een ‘posts’ directory geplaatst worden dat worden dan blog posts.html maar het systeem dat al die posts bestanden bij elkaar raapt als het ware en via een categorie systeem verbindt dat moet echt veel eenvoudiger en slimmer gedaan worden dan nu het geval is.

Ik zie overal Ruby voorbij komen als de programmeertaal die hier ideaal voor geschikt is maar ik weet niet zeker of dit de juiste manier voorwaarts is. Straks ben ik 3 dagen aan het leren en dan blijkt dat het totaal niet is wat ik moet hebben.

Profielfoto van Night

Night [moderator] op 08 augustus 2017 #

Als je dit vanuit een Mac oogpunt wil doen, wat houdt je tegen eens een blik op Swift te werpen..? Naast ‘gewone’ apps voor Mac, iOS en Apple Watch  is er vast een mogelijkheid een onaangeboorde goudmijn te creëren in jouw richting en een (al dan niet online uitvoerbare) fantastische static site builder te ontwikkelen.

Profielfoto van wsn79

wsn79 op 08 augustus 2017 #

PHP=> OctoberCMS, Zend Framework 3, Laravel 5.4.
.NET=> TeleRik
Python => Django
Ruby => Rails

Wat een serversided scripttaal doet, die neemt de aanvraag van de gebruiker (endpoint reqeust) en geeft dan data terug bijv. mijndomein.nl/blog/koffie/mijn-bezoek-aan-beans-and-bagles. Dit kan een statische pagina zijn, maar het kan ook content zijn uit een MySQL database, een JSON bestand of een actuele fetch van een webservice (bijv een call naar het knmi, de nos of de ns site), en ja die geven html terug. Wil je dynamischer dan HTML, dan heb je in een moderne browser keuze uit diverse javascript-framworks die ook html genereren. Deze generators werken echter cleintside. Laravel kent Lumen als microframework en dan kun je met Vue.JS een visuele laag bovenop doen eventueel met instructies voor bootstrap css vanuit een yaml (yet another markup language). Je kunt ook een eenvoudig php script maken wat .html files schrijft op basis van yaml en sql.

Swift doet geen serverside scripting zoals PHP, JSP, Ruby en .NET (C#) dat wel doen maar je zou natuurlijk een dataservice op je server kunnen inrichten die via oath data pushes vanaf je telefoon, ipad of mac krijgt vanuit een applicatie. Een beetje wat Adobe contribute deed, 15 jaar geleden in de tijd van flash en activex. Scala heeft infochannel ontwikkeld omdat voor instore tv systemen te doen, rock solid, pure java en zelfs na 8 jaar en diverse updates draait dat nog steeds erg goed.

Profielfoto van Night

Night [moderator] op 08 augustus 2017 #

Klinkt als een leuke uitdaging dan (als je dat zoekt). Ik denk met de huidige Swift ontwikkelingen zelfs een gat in de markt…

Profielfoto van Finch

Finch op 08 augustus 2017 #

Als je dan verder gaat met Swift is Vapor een mooi iets om in te duiken.

Server Side Swift
Create modern web apps, sites, and APIs using HTTP or real-time apps using WebSockets.

Fast
Nearly 100x faster than popular web frameworks using Ruby and PHP. Swift is fast by every meaning of the word.

Secure
Trusted encryption and TLS from OpenSSL and BCrypt hashing is included by default to make security easy.

Extensible
With middleware and Swift extensions, you can add custom functionality to Vapor that feels native.

Expressive
The static type system allows you to write less and do more. Vapor apps are very concise and even more powerful.

Fun
With autocomplete, debugging, and breakpoints you’ll spend more time creating and less time fixing.

  • Deze reactie is gewijzigd 4 maanden, 1 week geleden door Profielfoto van Night Night. Reden: URL aangepast
Profielfoto van Shmoo

Shmoo op 08 augustus 2017 #

Swift en echt programmeren is extreem moeilijk, dat gaat boven mijn niveau en daar ben ik helaas niet slim genoeg voor.:)

Wat jij bedoelt is een macOS compiler app bouwen en dat heeft iemand al gedaan. Een heel erg goede indie developer. CodeKit.

Build folder systeem, JavaScript en Sass compiler, Image optimizer en alles zit er gewoon in verwerkt. Dit is voor eke web developer op de Mac echt wel een must have.

Dit is natuurlijk al geweldig maar vooral fijn wanneer het echt static-static moet zijn. Stel je bent echt een HTML/CSS freak en je wilt lekker voor jezelf iets snel bouwen of iets dat nooit aangepast dient te worden dan is dit echt ideaal. Drop een bestand in een folder en de app maakt er een .html pagina van. Daar komt zelfs geen Command Line bij kijken en dat regelt de app allemaal op de achtergrond.
Echter zodra je ook maar iets verder wilt gaan kijken dat static-static HTML pain genereren kom je al heel snel in de problemen met deze app.

De ontwikkelaar heeft zelfs een eigen taal ontworpen genaamd Kit. ( HTML met eigen verzonnen comments )
https://codekitapp.com/help/kit/

Kit is open source in de zin van dat andere app developers de taal kunnen integreren in hun apps alleen is Kit niet volwassen genoeg tegenover Jekyll en Middleman systemen die gebruik maken van Ruby, GEMS en weet ik veel wat voor ’n kermis allemaal.

— niet lachen als ik er compleet naast zit —

Volgens mij werkt het zo in de programmeer-wereld.  Stel je zou een blog post aanmaken dan heb je een (global) object nodig en in dit geval is het object dan Post omdat het een blog post is. Volgende stap, om de titel van de post te krijgen doe je iets in de trant van post.title (object + title) zoiets zie ik in Liquid veel gebeuren. Liquid is een template language dat ontworpen is door Shopify (mega ruig bedrijf overigens) en geschreven in Ruby.

Zie dit voorbeeld. Onderstaande code print als het ware de titel van een product op een pagina.

Echter, nu komt het heel wirwar waar ik mee zit. Wat ik niet begrijp is dat hele object gebeuren. Als er geen database is hoe komt dat object dan aan z’n informatie.
Bij WordPress begrijp ik dat wel. Er zijn functions die functions kunt e gebruiken en die praten dan met de database op bepaalde informatie aan de hand van een Post_ID op te halen. De titel, content het zit allemaal in vakjes (cellen) in de database dus dan kan opgehaald worden wanneer je de Post_ID hebt maar bij dit systeem ontgaat mij dat totaal hoe dat werkt.

Profielfoto van wsn79

wsn79 op 08 augustus 2017 #

{{ product.title }} dit is dus de exacte syntax van Twig in OctoberCMS of Smarty in bijvoorbeeld Prestashop.

product is je model dus het soort ‘ding’ wat je uit je database of JSON haalt. title is de node waar in de string met de productnaam zit.

Zonder database heb je altijd nog JSON (JavaScript Object Notation) of XML etc etc doet ongeveer het zelfde als een database. Er zijn ook hybridevormen zoals de HHVM van Facebook die parsing en storage enigsinds laten overlappen. Omdat databases vlot te maken gebruiken webdevelopers ORM, object relational mapping zoals Eloquent in Laravel of Doctrine in Zend. Je kunt ook met javascript een andere pagina uitlezen die gegevens overnemen in JSON en dan tonen. Dat heb ik gedaan met een website die vakanties verkoopt en via een jqeury request haal ik dan de prijs en beschikbaarheid van vliegtuigstoelen en hotels op, voeg daar marge aan toe, en zet het in de etalage, pas als de klant gaat boeken, komt de database in zicht. Daarmee doet de computer (clientside) van de klant al het zoekwerk naar actuele prijzen en hoeft het reisbureau alleen maar tickets te verkopen…

Klinkt misschien heel stom, maar waarom zou je een serversided script taal willen bouwen in iets als Swift? Ik bedoel kijk naar de .NET en PHP featurelist en bugfixes, voordat je zoiets acceptabel maakt ben je jaren verder. Ja, front end is lastig, iedereen wil alles de moeder responsive en alles met sliders, parallaxen en andere grafische hoogstandjes, een videoclip op je landing die toch google pagespeed niet over de zeik laat gaan, etc etc, en het moet ook nog eens werken in IE9!! Dat is de reden waarom bootstrap redelijk complex is, maar met een webpack dusdanig aan te passen is dat een browser een pakketje krijgt aan CSS en javascript wat precies bij die browser past en daarme een snelle en goede pagina -voor de computer of device die je gebruikt- geeft of je nu op oma’s 386DX40 met Windows 3.11 zit of een over de top i9 computer met 21:9 6K monitor, danwel een prepaid stuk ellende van de kruidvat met een 320×240 schermpje of een over de top phablet phone met 4K scherm.

Je zou eens moeten kijken hoe Twig of Smarty werken en dat proberen in te sluiten op een framework in swift.

Profielfoto van feek

feek op 08 augustus 2017 #

Jekyll haalt die gegevens uit jml (YAML) bestanden. In deze config bestanden kan je diverse (globale) objecten definiëren. Ook in de metadata van bv een Jekyll post (markdown file) kan je aanvullende variabelen / objecten definiëren.  Aangezien deze posts in Jekyll ook een soort (interne) post_ID hebben / krijgen tijdens het renderen (ik weet niet meer precies hoe) kan de deze ‘oproepen’ elders in je code.

zie hier voor een datafile

Profielfoto van Night

Night [moderator] op 11 augustus 2017 #

Nou, @shmoo: Eat your heart out:-D

Profielfoto van Shmoo

Shmoo op 11 augustus 2017 #

Ik ben gewonnen met het leren van Ruby omdat de meeste static site generators daar gebruik van maken en ik moet zeggen het gaat mij best goed af. Er zitten veel vergelijkingen in met PHP waardoor ik het makkelijker begrijp.

Al heb ik wel iets van een extra cursus nodig rondom het hele ‘object oriented programming’ gebeuren. Zodra er Classes en dat soort dingen in voorkomen dan begin ik al snel de weg kwijt te raken dus dat moet ik iets beter onder de knie krijgen.

https://www.ruby-lang.org/en/

Als ik daar klaar mee ben ga ik mij verdiepen in hoe ik YAML en Liquid in Ruby code kan integreren.
https://shopify.github.io/liquid/

En als dat werkt hoop ik dat ik met Electron apps kan bouwen die dit hele process kunnen genereren.
https://electron.atom.io

Goed dat zal wel een jaartje werk zijn.:)

Profielfoto van feek

feek op 11 augustus 2017 #

Succes Shmoo!

Ben benieuwd naar het resultaat. Ga je dan Jekyll gebruiken en eigen modules / plugins schrijven?

Ik ga er van uit dat je jouw statische sites dan ‘lokaal’ gaat genereren. Want er zijn maar erg weinig hosting bedrijven die Ruby aanbieden (icm ssh toegang).  

Hier kan je vast wat Ruby en Liquid inspiratie vinden.

Profielfoto van Shmoo

Shmoo op 12 augustus 2017 #

Ja klopt.

Het ‘probleem’ dat ik vooral wil wegnemen (in een ideale wereld natuurlijk) is dat je voor elk systeem jezelf weer opnieuw moet inleven in het nieuwe systeem. Natuurlijk is dat geen probleem wanneer je gewoon 2 of 3 dagen door de Codex of Docs pagina’s kunt bladeren maar wij weten allemaal dat het niet zo werkt. Daar zal je alleen van leren hoe je … installeert en hoe bepaalde standaard dingen werken. Wanneer je fundamenteel iets wilt gaan wijzigen dan heb je bijna voor elke functie of beweging in de bestanden wel een Google zoekopdracht nodig. Dat duurt echt gemiddeld een jaar of 7 projecten/sites/opdrachten voordat je iets nieuws hebt aangeleerd en je er echt mee kunt werken zonder alles op te hoeven opzoeken.

Dus wat ik zou willen bereiken, als mij dat lukt natuurlijk. Is een app bouwen dat lokaal op je computer van Markdown bestanden (met YAML Frontmatter) HTML pagina’s genereert, precies zoals Jekyll, Middleman en al die andere ook doen, met enkel twee verschillen.

1) De Terminal moet weg uit deze workflow en daar moet een eenvoudige app zoals CodeKit of Hammer for Mac met Build folder systeem voor in de plaats komen dat op basis van Ruby werkt. Je dropt je bestanden in de source folders > ramt bijv. op de knop ‘Compile’ en er wordt een site gemaakt van je tekstbestanden > uploaden klaar.
2) De template langue mag Liquid (syntaxt) based zijn zoals Jekyll of vele andere dat ook gebruiken, daar is niet zo veel mis mee maar het moet wel vooral veel vergelijkingen hebben met de functions zoals je die in WordPress gebruikt waardoor je direct herkenning krijgt in wat je doet en de overstap van WordPress naar een static site generator veel makkelijker wordt.

Voorbeeld.
<?php echo get_title(); ?> of <?php the_title(); ?> in WordPress  mogen  best  {{ post.the_title }} of {{ site.the_title }} of {{ product.the_title }} worden dus met een object er voor om aan te geven in welke ‘post_type’ je zit maar dit is wel direct meer herkenbaar los van de verschillende code syntax. Natuurlijk is dit een super eenvoudig voorbeeld iets dat je snel zult oppikken en niet meer vergeten maar wanneer je met loops gaat werken of met page navigaties kom je al snel in een hell van spaghetti terecht en laat staan dat er ook maar ergens standaard boolean ingebouwde controles voor zijn in liquid om te controleren of een method empty is of niet.

Ik heb de hele Jekyll cursus gekeken op Lynda.com en het was best wel goed moet ik zeggen maar ik kon zeker 10 keer in het project zien dat hij ergens {% liquid syntax %} gebruikte tussen HTML tags waarvan ik dacht. En wat als bijv. een bewerkingsdatum nog niet aanwezig is ? dan heb je dus lege HTML tags in je broncode want er wordt nergens gecontroleerd of er wel een bewerkingsdatum is. Is deze er niet dan wordt gewoon over die Liquid syntax heen gelezen alsof deze niet aanwezig was en niets naar de pagina geprint  – kortom, je bent overal conditionals IF en ELSE aan het toevoegen wanneer je het goed wilt doen. WordPress had hier in het begin natuurlijk ook veel last van en de before and after args zijn pas veel later toegevoegd maar dat wilt toch niet zeggen dat je er in Liquid niet nu meteen mee moet beginnen maar misschien ben ik wel gek.

Ik denk dan aan zoiets, dat is herkenbaar vanuit vergelijkbare WordPress functions met een before and after wrapper die alleen getoond worden wanneer de method true is. (die double quotes in de string zullen niet samenspelen, nee)

{{ post.the_modified_date | ‘<time class=”update”>’, ‘</time>’ }}
https://codex.wordpress.org/Function_Reference/the_modified_date

Nog zo’n dingetje..
Om bijv. een lijstje met categorieën of tags op te bouwen (tag cloud) ben je in Jekyll/Liquid wel even bezig (zie de Dropbox link in mijn openingspost). Dat gun je toch niemand om zoiets in je template files tussen je HTML in te moeten bouwen op die manier. Laat staan weer, wanneer je nog helemaal geen tags hebt. Zie je weer die empty list zonder

  • items.
    Een Tag Cloud is toch niet iets dat nooit op een site voorkomt. Dan is het toch veel verstandiger dat je dit als standaard methode of functie in je library opneemt en die hele loop constructie al maakt zodat men alleen maar {{ site.the_tag_cloud | args }} hoeven te gebruiken of zoiets.

    Het zijn maar wat ideetjes en ja het kost je waarschijnlijk 5 jaar van je leven om alle WordPress functies over te porten naar een Liquid syntax – herschreven in Ruby maar dat is de motivatie ook niet want je wilt het juist basic houden en niet over de top gaan doen wat WordPress nu doet.
    Je stopt alleen de veel gebruikte functies in de core en wanneer iemand  zelf iets unieks knutselt laat je die gewoon via hooks in haken.

    Ik heb vandaag al geleerd hoe je ‘load’ en ‘require’ gebruikt in Ruby en ook hoe je dus andere bestanden kunt vinden, inlezen en erin schrijven. Natuurlijk makkelijk gezegd “al geleerd”. Als je het geleerd hebt heb je het nog niet gedaan in de praktijk en zit je vol passie om het uit te voeren.

    Haha, gelukkig heb ik de komende ± 8 maanden vrij.

  • Profielfoto van wsn79

    wsn79 op 12 augustus 2017 #

    Ik moet zeggen dat met 8 jaar ervaring in zowel Java, C# en PHP veel talen erg veel op elkaar lijken. In de wereld van het grote programmeren werk je continu aan andere klussen en doe je soms dingen door elkaar. Embedded systemen werken veel met java, console-games waarbij de vertaling van engels naar nederlands gechecked moet worden werken bij het ene platform in C#, het andere in Java maar wel met veel van dezelfde constructies. Als je 2 jaar in bijvoorbeeld PHP helemaal kan redden, dan is C# ook zo geleerd, vanwege de zeer sterkte hang naar objecten zou ik met Java nog even wachten. En dan bouw je een desktop applicatie voor een ziekenhuis, een ELO-website voor een school met een desktop app voor het bijhouden van resultaten en een stuk firmware voor een parkeerautomaat in een maand tijd, kris kras door elkaar.

    WordPress daar heb ik een schijthekel aan, te weinig kwaliteitscontrole voor wat betreft alle plugins. OctoberCMS of Zend Framework 3 zijn veel beter en veel veiliger.

    Profielfoto van TheBigZ

    TheBigZ op 16 augustus 2017 #

    Shmoo op 08 augustus 2017

    … maar dat moet er wel een eenvoudigere manier zijn om een blog systeem toe te voegen.  Dus bestanden die in een ‘posts’ directory geplaatst worden dat worden dan blog posts.html maar het systeem dat al die posts bestanden bij elkaar raapt als het ware en via een categorie systeem verbindt dat moet echt veel eenvoudiger en slimmer gedaan worden dan nu het geval is.

    Al eens overwogen om dat in Javascript te doen?

    In deze uitgebreide Vue.js tutorial (een serie van 44 (!) filmpjes) wordt onder meer uitgelegd hoe je je eigen blog kunt maken in Javascript. (In de laatste twee afleveringen van de serie wordt de koppeling met Firebase behandeld.)

    Profielfoto van Shmoo

    Shmoo op 16 augustus 2017 #

    Bedankt voor je bijdrage, het filmpje heb ik in mijn lijstlijst gezet zodat ik ‘m vanavond of zo kan kijken. Meestal zit ik op YouTube wanneer ik naar bed ga dan kijk ik allerlei filmpjes.

    In het begin heb ik heel erg aan een Javascript manier gedacht maar omdat er op dit moment zoveel populaire frameworks en poespas is in het hele Javascript gebeuren actief is ben ik daar een beetje afstandelijk voor geworden omdat je op zo’n moment ook heel snel op de verkeerde framework kunt inspringen. Dan begin je met iets nieuws leren en dan ben je half jaar verder en dan blijkt dat je toch het verkeerde hebt gekozen. Ik leer sowieso al niet snel en moet alles 6 keer overlezen voordat ik het begrijp dus vandaar dat ik niet meteen op nieuwe dingen spring.

    Profielfoto van TheBigZ

    TheBigZ op 16 augustus 2017 #

    The Net Ninja (uit Manchester) heeft een heleboel (gratis) goede tutorials over HTML, CSS, Javascript en alles wat daarna komt, zoals bijvoorbeeld vue.js. Het kost wat tijd om het te bekijken, maar het wordt allemaal duidelijk uitgelegd (vind ik).

    Profielfoto van TheBigZ

    TheBigZ op 27 augustus 2017 #

    En als je liever tekst leest dan filmpjes kijkt, in dit artikel wordt uitgelegd hoe je een vergelijkbare app maakt.

    Getting started with modern front-end development with Vue.js

    Over dit topic

    Gestart op 08 augustus 2017 door Shmoo

    Laatste reactie door TheBigZ

    Je kunt alleen reageren met een gratis OMT account.
    Heb je geen OMT account? Registreer je dan nu gratis!

    Inloggen

     

    of Wachtwoord resetten?