1. #1456
    Scissor's Avatar
    Registered
    14/09/02
    Posts
    1,088
    iTrader
    0
    Mentioned
    0 Post(s)
    Reputation
    0/0
    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  

  2. #1457

    Registered
    14/08/10
    Location
    Diest
    Posts
    2,419
    iTrader
    1 (100%)
    Mentioned
    0 Post(s)
    Reputation
    8/16
    Quote Originally Posted by Scissor View Post
    This quote is hidden because you are ignoring this member. Show
    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.
    Opslaan als JPG op 80% quality?
    no votes  

  3. #1458
    adrianhates's Avatar
    Registered
    23/01/06
    Posts
    2,115
    iTrader
    0
    Mentioned
    0 Post(s)
    Reputation
    23/23
    Quote Originally Posted by Dieterg View Post
    This quote is hidden because you are ignoring this member. Show
    Ik zie het toch wel wat anders :-)..

    Om een voorbeeld te geven: Bij mijn vorige projecten begon ik altijd van de back-end naar de front-end te werken. Eerst zorgen dat de database etc in orde was.

    Nu met (bv.) AngularJS begin ik aan de front-end, als data maak ik gebruik van JSON-Objecten. Als de front-end klaar is begin ik aan de back-end, bijvoorbeeld een REST Client. Die REST client kan dan gebruik maken van de front-end JSON objecten die ik doorstuur of afhaal. Zo is server side taal en client side taal 100% gescheiden, geen rommelcode meer. Er is orde aan zowel de client als aan de serverkant. Ik zie ook dat ik nu minder lang bezig ben geweest aan dit project én een pak minder code!!

    Een REST client heeft dan ook nog eens het voordeel dat er snel een ander soort applicatie aan kan toegevoegd worden zonder dat er iets aan de back-end moet veranderen.

    AngularJS voelt imo zeer natuurlijk aan, als ik met jQuery/puur javascript bezig ben heb ik steeds het gevoel dat ik aan het 'hacken' ben.
    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  

  4. #1459
    W0utR's Avatar
    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  

  5. #1460
    Dieterg's Avatar
    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  

  6. #1461
    Moto's Avatar
    Registered
    17/07/02
    Location
    Wilrijk
    Posts
    1,994
    iTrader
    2 (100%)
    Mentioned
    0 Post(s)
    Reputation
    9/16
    Ik was aan het denken om het in node.js te doen, maar andere suggesties zijn altijd welkom.
    node.js is wel leuk en dan kunt ge gaan voor het traditionele Express framework
    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


    Wat niet wegneemt dat de backend logica en database design nog steeds een grote brok blijven.
    Vind daar nu meestal niks aan, ik snap niet hoe daar veel tijd voor nodig is tov UI
    no votes  

  7. #1462
    W0utR's Avatar
    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  

  8. #1463
    Shaddix's Avatar
    Registered
    08/09/09
    Posts
    6,121
    iTrader
    23 (100%)
    Mentioned
    9 Post(s)
    Reputation
    3/121
    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  

  9. #1464
    Moto's Avatar
    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  

  10. #1465
    Moto's Avatar
    Registered
    17/07/02
    Location
    Wilrijk
    Posts
    1,994
    iTrader
    2 (100%)
    Mentioned
    0 Post(s)
    Reputation
    9/16
    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"
    Eerder oppassen voor developers die de foute technologie kiezen of ze verkeerd toepassen
    no votes  

  11. #1466
    bealzebub's Avatar
    Registered
    28/06/06
    Location
    Gent
    Posts
    376
    iTrader
    1 (100%)
    Mentioned
    0 Post(s)
    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  

  12. #1467
    dJeez's Avatar
    Registered
    17/07/02
    Location
    Sol System
    Posts
    10,064
    iTrader
    1 (100%)
    Mentioned
    0 Post(s)
    Reputation
    27/78
    Quote Originally Posted by bealzebub View Post
    This quote is hidden because you are ignoring this member. Show
    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), …
    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 alieno
    Pastafarian by choice
    no votes  

  13. #1468
    Moto's Avatar
    Registered
    17/07/02
    Location
    Wilrijk
    Posts
    1,994
    iTrader
    2 (100%)
    Mentioned
    0 Post(s)
    Reputation
    9/16
    je komt die - terechte - kritiek enorm veel tegen op het net .
    Zelf nog geen problemen gehad tot nu toe

    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  

  14. #1469
    bealzebub's Avatar
    Registered
    28/06/06
    Location
    Gent
    Posts
    376
    iTrader
    1 (100%)
    Mentioned
    0 Post(s)
    Quote Originally Posted by Moto View Post
    This quote is hidden because you are ignoring this member. Show
    Zelf nog geen problemen gehad tot nu toe

    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"
    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  

  15. #1470
    Moto's Avatar
    Registered
    17/07/02
    Location
    Wilrijk
    Posts
    1,994
    iTrader
    2 (100%)
    Mentioned
    0 Post(s)
    Reputation
    9/16
    Ik meen toch te mogen zeggen dat wij goed weten waarmee we bezig zijn
    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 "

    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  

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

Log in

Log in