G/b/ tries: Terraria

Door Gamebuster op zaterdag 19 juli 2014 22:36 - Reacties (10)
Categorie: Gaming, Views: 2.554



Ik speel Terraria voor het eerst en lever commentaar over de microfoon. Gewoon, omdat het kan.

Ik vind het altijd leuk om gameplay video's te kijken en mijn interesse ligt er ook al een tijd om zelf video's te gaan maken. Dit is 1 van mijn pogingen. De video is niet bewerkt voor uploaden; Ik vond de video wel voldoende om zonder knippen te uploaden.

edit: Titel aangepast zodat gamenaam zichtbaar is in tweakblogs overzicht.

Groeperen op wat het doet of wat het is?

Door Gamebuster op woensdag 28 mei 2014 18:24 - Reacties (14)
Categorie: if(post.relatedTo("programming")), Views: 3.258

Bij grotere software pakketten groepeer je je code. Of je nou in C, Java, Ruby of Haskell werkt: Groeperen van code doen we allemaal. Voor ieder project waar je wat langer aan verwacht te werken, verschijnen al gauw meerdere bestanden. Voor nog grotere projecten verschijnen de mapjes. Bij frameworks wordt de mappen-structuur zelfs voor je afgedwongen of gegenereerd. Maar wat is eigenlijk de “juiste” manier?

Groeperen op wat het is
Is het een model? Een entity? Een controller? Een view? Bij frameworks als Rails zie je vaak een mappen-structuur waarbij alle modellen onder de “models” map vallen, alle controllers onder de “controllers” map vallen en alle views onder “views”.

Zo heb je alles netjes bij elkaar. Wil je een view wijzigen? Prima, open de views map en leef je uit. Wil je je model wijzigen? Prima, open de models map. Klinkt niet verkeerd toch?

Stel, ik heb een Twitter applicatie gebouwd in een MVC framework als Rails. De modellen User en Tweet zitten in de models map, de controllers hiervoor in de controllers map en de views voor alle acties voor de controllers hiervoor zitten in de views map.

Nu wil je een veld toevoegen aan User. Je wil op iedere profielpagina een link toevoegen naar de website van de gebruiker; deze link kan de gebruiker zelf toevoegen.

Om dit te doen, moet je eerst de User model aanpassen: Je moet een homepage veld toevoegen. Je opent de models-map en voegt het veld toe. Nu moet je toevoegen dat de gebruiker dit veld kan invullen en bewerken. Je hebt al een gebruiker bewerken controller actie en view, dus je hoeft deze 2 alleen nog aan te passen. Je opent de controllers map en past de controller aan met een default value en een assignment van de input params naar het model. Verder open je de views map en pas je de view aan zodat er een veld zichtbaar wordt.

Nou is dit een vrij simpel voorbeeld. Complexer voorbeeld is een test driven applicatie. Al gauw heb je vele mapjes open in je file drawer. Je wijzigingen in de applicatie zijn verspreid over een wijd arsenaal aan mappen.

Groeperen op waarvoor het is
Stel nou dat je alles groepeert op wat het is. Je hebt een users-map met daarin de user-model, de users controller en alle views voor users. In dezelfde map zitten zelfs je tests, want we schrijven natuurlijk wel tests voor de software die we maken, toch?

Voor de bovenstaande aanpassing, hoeven we maar 1 map te openen: users. Daaronder zitten alle bestanden die we moeten wijzigen. De tests, de controller, het model en de views.

Alle wijzigingen zijn gegroepeerd onder 1 map. Je hebt niet hoeven zoeken naar alle bestanden die je nodig hebt. In dit is het direct duidelijk dat je alleen dingen hebt veranderd onder /users.

Wat vind jij?
Tot nu toe heb ik altijd gegroepeerd op wat het is, simpelweg omdat dat “the way to go” is bij frameworks als Rails, maar mijn recente loskoppeling van Rails heeft me aan het denken gezet of dat wel de meest efficiŽnte manier is voor mij.

Ik denk dat het gezond is je primaire mappen-structuur meer te focussen op wat de applicatie inhoudt (tweets, users) en niet wat er allemaal in zit (models, controllers, views)

Dus... Groeperen op wat het is, of waarvoor het is?

KERST

Door Gamebuster op woensdag 28 mei 2014 11:05 - Reacties (12)
Categorie: quite useless, Views: 2.360

Hebben jullie de kerstboom al staan?







Ruby on Rails: offtrack

Door Gamebuster op zaterdag 17 mei 2014 23:55 - Reacties (10)
Categorie: if(post.relatedTo("programming")), Views: 2.963

Na 3 jaar fulltime programmeren met Ruby on Rails heb ik besloten af te stappen van het framework.

Waarom? Hierom:

Plugins & Dependencies
Rails met de vele gems eromheen hebben naar mijn idee een te groot black box gehalte. Bestaande code en frameworks gebruiken is gebruikelijk een goed idee. In Rails projecten heb je echter gauw te maken met tientallen "eigen" dependencies (zoals opgegeven in je Gemfile) en 100en dependencies van de gems die je hebt ingeladen.

Natuurlijk ben je niet verplicht die gems te gebruiken. Maar waarom zou je het zelf maken als je een gem kan pakken die ongeveer doet wat je wil doen? Dit gaat gewoonlijk prima en je hebt snel resultaat.

Echter, nu blijkt na een jaar stabiel draaien en geen onderhoud dat er opeens wat moet veranderen... Oeps! De documentatie van oude versie van je gem is nergens meer te vinden; of de DSL van de nieuwe versie is compleet anders; of de nieuwe versie werkt niet meer samen met de nieuwe versie van een andere gem die ervan afhankelijk was.

Je zit dus vast aan die oude versie van die gem. Een heel netwerk aan gems kan je nu ook niet updaten zonder samenhangende gems weer te updaten, die weer hangen aan andere gems. In het ergste geval kan je zelfs je Ruby niet updaten, omdat er een enkele wazige feature uit een gem afhankelijk is van een wazige bug van een bepaald patchlevel van een bepaalde ruby. In sommige extreme gevallen start de hele applicatie niet meer en ben je uren of zelfs dagen bezig om je development omgeving weer draaiende te krijgen.

Je applicatie is geweven door deze dependencies. Je zit vast aan de gems. Devise, Cancan, MetaSearch, WillPaginate, enz. Je nieuwe feature vereist een stukje functionaliteit die al zit in een nieuwe versie van gem X, maar gem X is afhankelijk van gem Y. Je moet dus nu de functionaliteit van de nieuwe versie van gem X namaken of de oude versie zelf hotpatchen naar de nieuwe functionaliteit.

Voor je het doorhebt zijn alle dependencies leidend voor je applicatie en wordt je naar de grond getrokken om Łberhaupt de applicatie draaiende te houden.

Oplossing: Vermijd het gebruik van gems in kritieke delen van je applicatie...

Rails is je applicatie
Heb je een eigen Rails project? Denk mee met de volgende stelling:

Stel dat je de Rails gem, en al zijn bijbehoren componenten, zou verwijderen uit je project, welk deel van het project werkt dan nog WEL? Zeer waarschijnlijk kan je je project niet meer starten, maar dat is niet zo erg. Draaien de unit tests voor je domain logic nog, of heb je al je domain logic in Models of Controllers verwerkt? Doet je applicatie het zonder database? Stel dat je je database zou vervangen door een klein Ruby object die alles in-memory opslaat, werkt je applicatie dan nog, of moet je al je domain entities omschrijven zodat ze niet meer ActiveRecord::Base als basis hebben?

In de meeste gevallen is dat niet zo. Is het bij jouw project wel zo? Goed bezig!

In de Rails projecten die ik heb gezien, is Rails de leidende informatie over het project; Het feit dat het een "Rails project" genoemd kan worden, zegt al genoeg: Dat je "Rails" gebruikt als framework moet geen leidend feit zijn van je applicatie. Je moet rails uit je project kunnen verwijderen en alle functionaliteit die niet relevant is voor de presentatie voor het web zou moeten blijven werken.

Rails is hiervoor niet ontworpen. Rails is ontworpen leidend te zijn in je applicatie. Als rapid prototype is dit prima, maar als long-living applicatie is dit niet wat je wil.

...
Ik kan heel lang doortypen wat mijn kritiek is op Rails. Het heeft zo z'n goede kanten, maar de gehele MVC structuur zoals bij moderne web frameworks toegepast wordt, spreekt mij niet totaal aan. Views in Rails zijn ook niet om te genieten. Ik vind ERB verschrikkelijk, net als templating languages, HAML, enz.

Maar wat dan wel?

Ben ik nog niet volledig over uit. Ik wil alle features die ik gebruik van Rails herzien en kijken of ik het wil blijven gebruiken. Mijn huidige grootste project is een nieuw project die nu als rapid prototype is opgezet als Rails project. De business logic is echter groter dan het rails project; Het rails project is slechts een dunne presentatie laag over de core van de applicatie.

De code van de applicatie is nu geschreven als een gem, volledig los van elke dependency (pure Ruby en core libraries). De enige keren dat ik 3rd party libraries gebruik, is wanneer ik de functionaliteit nodig heb in een bepaalde module. De gehele 3rd party library wordt verborgen gehouden voor de rest van de applicatie, net zoals dat hoort.

Ik wil mijn views graag opbouwen in de vorm van modules, net zoals je bij AWT of Swing doet in Java. In realiteit zal dit betekenen dat mijn view "blokken" bestaan uit een grote hoeveelheid objecten die HTML genereren. Ik kan dan standaard view modules gebruiken (die ik gewoon kan recyclen tussen alle projecten die ik heb) en bijzondere functionaliteit kan ik als subclasses realiseren. Dit lijkt me lastig te realiseren, maar o wat zou ik het graag willen realiseren. Ik heb het een keer geprobeerd tot een zeker niveau en het beviel me goed.

Hoe dan ook, ik rond deze blog af. Film kijken, blog schrijven en late uren na drukke dag vormen een slechte combinatie.

Bad Grandpa (2013, Trailer)

Door Gamebuster op maandag 14 april 2014 12:32 - Reacties (12)
Categorie: quite useless, Views: 2.374



Wat de fuck, dit is een film