Thread: De koffiepauzehoek
-
06-01-2014, 22:54 #1456
Iemand een goede compressiemethode? Zit met images van 1Mb + die als backstretch dienen. Heb ze al door tinyPng gehaald en in photoshop gesaved voor web maar krijg ze maar niet tot een "redelijk" formaat.
no votes
-
-
06-01-2014, 23:19 #1457Deactivated user
- Registered
- 14/08/10
- Location
- Diest
- Posts
- 2,419
- iTrader
- 1 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 8/16
no votes
-
06-01-2014, 23:46 #1458
om eerlijk te zijn ben ik ook (onbewust) naar die methodologie aant shiften. Misschien ook omdat men thesis puur HTML5 en JavaScript betreft

tegenwoordig heb je met echt belachelijk weinig werk een goeie RESTful service opgezet. Wat niet wegneemt dat de backend logica en database design nog steeds een grote brok blijven. Wat me vroeger tegenhield was de JavaScript onzekerheid, maar dat mensen "mogelijks hun javascript afzetten" kan mij tegenwoordig gestolen worden.no votes
-
07-01-2014, 04:13 #1459Member
- Registered
- 16/04/08
- Location
- Hong Kong
- Posts
- 1,989
- iTrader
- 6 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 7/9
Ik ben momenteel bezig met een applicatie om te zetten in Ember.js, kwestie van het wat te leren.
Applicatie was vroeger geschreven in PHP en een hele hoop javascript code die onmogelijk nog te onderhouden is, nu, wat zouden jullie qua backend aanraden? Ik was aan het denken om het in node.js te doen, maar andere suggesties zijn altijd welkom.no votes
-
07-01-2014, 07:54 #1460Approved 9-lifer
- Registered
- 08/01/05
- Location
- Turnhout
- Posts
- 1,182
- iTrader
- 0
- Mentioned
- 0 Post(s)
- Reputation
- 9/9
ExpressJS: framework gebouwd bovenop Node.
Of ik vind webapi 2.0 (.NET) ook leuk om mee te werken.
Node/express is heel leuk maar kheb nog moeite met het structureren van men project. Net zoals dat ik dat ook had met oude javascript projecten.
Verstuurd vanaf mijn GT-I9300 met Tapatalk 4-no votes
-
07-01-2014, 09:23 #1461Member
- Registered
- 17/07/02
- Location
- Wilrijk
- Posts
- 1,994
- iTrader
- 2 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 9/16
node.js is wel leuk en dan kunt ge gaan voor het traditionele Express frameworkIk was aan het denken om het in node.js te doen, maar andere suggesties zijn altijd welkom.
iets waar ge veel mensen hoort over klagen is het programmeren met al die callbacks, en de makers van Express zijn begonnen aan een ander framework waar men dus niet meer met callbacks hoeft te werken namelijk koa
Koa - next generation web framework for node.js
Ik vind het vooral fijn om kleinere sites mee op te zetten boven op een mongodb, grootste nadeel voor intranet applicaties is dat ik geen automatisch windows authentication (kerberos) kan doen zoals bij IIS/ASP.net
Dus voor de meeste intranet apps gebruik ik nu een C# backend onder IIS met ServiceStack.Rest en Linq2Db
Ge kunt ServiceStack altijd vervangen door het iets mindere WebApi, maar qua ORM komt niks in de buurt van Linq2Db
Vind daar nu meestal niks aan, ik snap niet hoe daar veel tijd voor nodig is tov UIWat niet wegneemt dat de backend logica en database design nog steeds een grote brok blijven.no votes
-
07-01-2014, 09:45 #1462Member
- Registered
- 16/04/08
- Location
- Hong Kong
- Posts
- 1,989
- iTrader
- 6 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 7/9
Thanks, zal zeker ExpressJS eens bekijken, iemand anders had aangeraden om gewoon een REST api te schrijven in PHP omdat het over een vrij kleine applicatie gaat, maar 't is maar bij wijze van experiment, dus gaat sowieso in node.js zijn.
no votes
-
07-01-2014, 11:00 #1463
Met die javascriptframeworks moet er toch altijd wat opgepast worden. Soms wordt het alleen maar gebruikt omdat het zo'n buzztopic is geworden. Onlangs hoorde ik van een e-shop die amper in google werd opgenomen. De ontwikkelaar bevestigde "ja met zo'n javascript framework is het moeilijk meer dan 1 page te laten indexeren door Google"
no votes
-
07-01-2014, 11:02 #1464Member
- Registered
- 17/07/02
- Location
- Wilrijk
- Posts
- 1,994
- iTrader
- 2 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 9/16
en ook niet Socket.io vergeten (ipv Rest service)
of gewoon uw volgend klein project volledig naar de MEAN stack gaan (= googlebare term
)
MongoDb + Express + Angular + Node
ofja gewoon MEEN met Ember dan in uw geval
no votes
-
07-01-2014, 11:05 #1465Member
- Registered
- 17/07/02
- Location
- Wilrijk
- Posts
- 1,994
- iTrader
- 2 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 9/16
Eerder oppassen voor developers die de foute technologie kiezen of ze verkeerd toepassenMet die javascriptframeworks moet er toch altijd wat opgepast worden. Soms wordt het alleen maar gebruikt omdat het zo'n buzztopic is geworden. Onlangs hoorde ik van een e-shop die amper in google werd opgenomen. De ontwikkelaar bevestigde "ja met zo'n javascript framework is het moeilijk meer dan 1 page te laten indexeren door Google"no votes
-
07-01-2014, 12:47 #1466
Als je dan toch voor Node zou gaan raad ik Sails als framework aan. Ondersteunt zowel REST API als Websocket API. REST en request-response based socket calls krijg je gewoon out of the box, pubsub is een paar extra regels code.
Sails is trouwens een framework bovenop Express, dus je kan er indien nodig gewoon middleware van Express tussen steken. Voor de frontend code gebruikt het Grunt, dus ook daar kan je de defaults van het framework makkelijk vervangen door iets anders (Angular, Ember, …). Voor de rest krijg je echt wel veel: router, orm, policies (authorization), …
Pas in ieder geval op met MongoDB. Het is zeker geen slechte NoSQL db en enorm populair, maar wij hebben er al stoten mee tegengekomen die minder aangenaam zijn eens je met veel data zit: corrupte db, memory usage die alle verbeelding tart (mongo neemt gewoon wat ie kan pakken), … Transacties bestaan als dusdanig ook niet in Mongo, je hebt enkel atomic operations op één document. Durability is ook iets wat je expliciet moet aanzetten (journaling) en staat niet helemaal op punt ook. Als je mongo visueel moet voorstellen is het een bak waar je losweg dingen ingooit en waar je ervan uitgaat dat het er wel in zal zitten. Als een document-based storage is het wel een goeie keuze, maar eens je met complexere relaties waar joins een betere piste zijn laat je het beter links liggen.no votes
-
07-01-2014, 22:43 #1467Member
- Registered
- 17/07/02
- Location
- Sol System
- Posts
- 10,064
- iTrader
- 1 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 27/78
Waar heb ik dat nog gelezen? Retorische vraag overigens, je komt die - terechte - kritiek enorm veel tegen op het net
.
Maar heeft er iemand ervaring met Graph DBs, dus dingen zoals OrientDB? Dat lijkt mij nl. de perfecte match voor dat probleem (best of both worlds). In hoeverre het de verwachtingen ook kan inlossen is echter een andere zaak (heb er nog niet mee gespeeld, maar zou dat wel eens willen doen
).
PSN: dJeezBE - Delicious bookmarks
Disclaimer: I am currently suffering from severe CSD (Compulsive Sarcasm Disorder). - L'onion fait la farce - Facile largire de alienoPastafarian by choiceno votes
-
08-01-2014, 02:12 #1468Member
- Registered
- 17/07/02
- Location
- Wilrijk
- Posts
- 1,994
- iTrader
- 2 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 9/16
Zelf nog geen problemen gehad tot nu toeje komt die - terechte - kritiek enorm veel tegen op het net .
En veel van die kritiek is ook weer onder te brengen onder "Niet de juiste technologie-keuze" of "Geen kennis van de technologie die men gebruikt"no votes
-
08-01-2014, 11:49 #1469
Wij wisten wel waaraan we begonnen, er waren zelfs uitvoerige stack tests vooraf gedaan. De toepassing waar het om draait is ook een NoSQL schoolvoorbeeld: documentgestructureerde data, geen joins, geen nood aan transacties, nood aan snelheid. Ik meen toch te mogen zeggen dat wij goed weten waarmee we bezig zijn en dat elke keuze van technologie eentje is waar we met een onderbouwde redenering voor gekozen hebben.
Nu, bijna alles wat ik zeg wordt gewoon rechtuit op de mongodb site vermeld: FAQ: MongoDB Fundamentals ? MongoDB Manual 2.4.8
Zolang je met weinig data zit is corruptie zelfs geen zo'n groot probleem, de recover functie werkt echt wel naar behoren. Eens je met een dataset zoals de onze zit (een catalogus om u tegen te zeggen) duurt een recover een halve dag. Je moet gewoon voor een mission critical app redundancy/replication voorzien, want corruptie kan optreden door factoren die niets met kennis van technologie of fout gebruik te maken hebben. De meest gekende is wanneer je een electriciteitspanne hebt en de mongodb niet correct wordt afgesloten, maar da's verre van het enige. Anyway, replicatie vangt dat probleem op, maar voor grotere projecten hangt daar een aanzienlijk prijskaartje aan vast. Durability is gewoon een issue en je zorgt er best voor dat je daar de nodige maatregelen voor treft als dat belangrijk is voor je app.
Mongo heeft z'n succes vooral te danken aan het feit dat het zo simpel is. En nogmaals, ik zeg niet dat je Mongo niet moet gebruiken. De andere opties waren CouchDB of Cassandra geweest maar die hadden dan weer andere nadelen. Zouden we vandaag een andere keuze maken… da's een moeilijke vraag… Bij problemen zeggen we ieder keer van wel, maar op andere momenten plukken we wel de vruchten van onze keuze (zelfs onder massive load blijft mongo gewoon snel).
Mongo is eigenlijk een beetje een puber: enorm dynamisch en wild enthousiast, maar soms zou je hem eens een goeie lap rond z'n oren willen geven als ie weer eens zonder nadenken zichzelf in de miserie heeft gestoken. Maar er is hoop, mongo is stillekesaan volwassen aan t worden en die puberstreken zullen dus mettertijd wel verdwijnen. Elke new kid on the block heeft trouwens dat probleem, en elke ouwe rot heeft dan weer het probleem dat ie naast uiterst betrouwbaar ook een beetje vastgeroest zit en alles wa minder rap gaat.no votes
-
08-01-2014, 14:56 #1470Member
- Registered
- 17/07/02
- Location
- Wilrijk
- Posts
- 1,994
- iTrader
- 2 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 9/16
Dit is dan ook een ander verhaal dan in uw voorgaande post die begon met "maar wij hebben er al stoten mee tegengekomen ... . .. Transacties bestaan als dusdanig ook niet in Mongo, je hebt enkel atomic operations op één document "Ik meen toch te mogen zeggen dat wij goed weten waarmee we bezig zijn
maar had het eigenlijk ook over de vele kritische posts tegen mongoDb op bv hacker news, waar veel punten die ze aanhalen hun eigen fout is.
Bij het switchen tussen relationele databases voor deftige projecten zult ge u in veel gevallen ook eerst moeten informeren naar de specifieke implementatie / technische verschillen.
nogal logisch dan dat wanneer ge van een relationele naar een in-memory document-db gaat ook eerst eens wat artikels leest
no votes

