abonnement Unibet Coolblue Bitvavo
  donderdag 8 mei 2014 @ 12:10:28 #211
12221 Tijn
Powered by MS Paint
pi_139693536
quote:
14s.gif Op donderdag 8 mei 2014 12:05 schreef KomtTijd... het volgende:

[..]

Dat hoeft ook helemaal niet. Waarschijnlijk zouden we 90% van de functies nieteens gebruiken en moeten er alsnog heel veel functies bijgeschreven worden. En dat is een handicap die veel kant-en-klaar pakketten hebben. Ze zijn zo uitgebreid mogelijk om een zo breed mogelijke markt te bedienen, maar een maatwerkoplossing hoeft vaak maar een fractie van die functionaliteit te bevatten. En is daardoor ook veel sneller te ontwikkelen en makkelijker te onderhouden.
Precies. Kleine bedrijven doen over het algemeen maar 1 ding en willen daarom een IT-product dat goed aansluit bij dat ene ding. Dat vind je zelden bij generieke software, terwijl het vaak wel goed te doen is om die ene functie op maat te maken.
pi_139694540
quote:
2s.gif Op donderdag 8 mei 2014 12:10 schreef Tijn het volgende:

[..]

Precies. Kleine bedrijven doen over het algemeen maar 1 ding en willen daarom een IT-product dat goed aansluit bij dat ene ding. Dat vind je zelden bij generieke software, terwijl het vaak wel goed te doen is om die ene functie op maat te maken.
Ik ben genoeg van dit soort software gedrochten tegengekomen, en mijn ervaring is dat men er substantieel geld mee verliest omdat de software niet naar behoren werkt of niet aangepast kan worden.
🕰️₿🕰️₿🕰️₿🕰️₿🕰️₿🕰️ TikTok next Block
  donderdag 8 mei 2014 @ 12:42:03 #213
12221 Tijn
Powered by MS Paint
pi_139694782
quote:
0s.gif Op donderdag 8 mei 2014 12:35 schreef raptorix het volgende:

[..]

Ik ben genoeg van dit soort software gedrochten tegengekomen, en mijn ervaring is dat men er substantieel geld mee verliest omdat de software niet naar behoren werkt of niet aangepast kan worden.
Tsja, uitvoering is alles. Natuurlijk wordt er een hoop rommel geschreven, maar dat wil niet zeggen dat het per se een slecht idee is om een maatwerkoplossing te laten maken.
pi_139705924
quote:
0s.gif Op donderdag 8 mei 2014 08:03 schreef raptorix het volgende:

[..]

Ehm, wij werken met een team van een man of 10 ongeveer een jaar aan 1 webshop, en dan gebruiken we ook nog eens een enterprise product, maar goed als jij denkt dat een webshop iets simpels is....

Vandaar dat met mensen als jou de kwaliteit van 99 procent van de webshops bedroevend is.
"met mensen als jou" :')

Dat jullie 10 kleuters zonder enige kennis van webshops aan het werk zetten om er een te bouwen betekent niet dat andere bedrijven wel kennis in huis hebben.

Je kan nog niet eens een paar zinnen foutloos typen, wat zegt dat over jullie code.

Als we toch op zo'n lekker bedroevend niveau aan het discussiëren zijn.
pi_139713364
quote:
0s.gif Op donderdag 8 mei 2014 08:33 schreef mstx het volgende:
Zolang de tabellen en kolommen maar logische namen hebben. Opencart heeft bijv. ook 115 tabellen maar daar heb ik de documentatie nog nooit voor nodig gehad. Veel simpeler kan het ook niet:
[ code verwijderd ]

Al vaak importscriptjes gemaakt om producten te importeren vanuit csv/xml/db en dat was zo gedaan.

Ter vergelijking, Magento:
[ code verwijderd ]

:')
Het probleem is dat ze qua structuur volledig vrij willen zijn en toch een MySQL database willen gebruiken. Dat komt waarschijnlijk omdat OpenCart en Magento al een poosje bestaan en er toen niet echt alternatieven waren. Als je nu een webshop gaat schrijven, zou ik serieus kijken naar een NoSQL database (bijvoorbeeld MongoDB of ArangoDB) gebruiken om de producten in op te slaan. En waarschijnlijk ook voor de rest van de data.
pi_139717204
quote:
1s.gif Op donderdag 8 mei 2014 10:56 schreef Robuustheid het volgende:

[..]

Je zou bijvoorbeeld in PHP een library kunnen oproepen met daarin de kleuren. Maar voor de overzichtelijkheid, stop ik de kleuren in een array.
Dat zou bijv. kunnen uitzien:
[ code verwijderd ]

Op die manier doorzoek je de array wel twee keer, eerst voor in_array en daarna voor array_search.

1
2
3
4
5
6
7
<?php
$colors 
= array("red""blue""yellow");
$index array_search('blue'$colors);
if (
$index !== false) {
    echo 
$index;
}
?>
pi_139730042
quote:
0s.gif Op donderdag 8 mei 2014 21:00 schreef Light het volgende:

[..]

Het probleem is dat ze qua structuur volledig vrij willen zijn en toch een MySQL database willen gebruiken. Dat komt waarschijnlijk omdat OpenCart en Magento al een poosje bestaan en er toen niet echt alternatieven waren. Als je nu een webshop gaat schrijven, zou ik serieus kijken naar een NoSQL database (bijvoorbeeld MongoDB of ArangoDB) gebruiken om de producten in op te slaan. En waarschijnlijk ook voor de rest van de data.
NoSQL is een prima ontsluiting van je data, maar ik zou er echt geen klant of transactie gegevens in gaan opslaan, overigens kun je binnen een magento of Opencart of welk ander product ook prima noSQL inzetten, het is gewoon een questie van je data pushen naar je noSQL server, kun je zowel realtime als in batch doen.
🕰️₿🕰️₿🕰️₿🕰️₿🕰️₿🕰️ TikTok next Block
pi_139730433
quote:
0s.gif Op vrijdag 9 mei 2014 06:45 schreef raptorix het volgende:

[..]

NoSQL is een prima ontsluiting van je data, maar ik zou er echt geen klant of transactie gegevens in gaan opslaan, overigens kun je binnen een magento of Opencart of welk ander product ook prima noSQL inzetten, het is gewoon een questie van je data pushen naar je noSQL server, kun je zowel realtime als in batch doen.
Waarom geen klantgegevens en transacties in NoSQL?
En Magento en OpenCart bieden nu (voor zover ik weet) geen mogelijkheid om productgegevens in NoSQL op te slaan. In plaats daarvan komen ze met een mega-hoeveelheid tabellen in MySQL om maar een flexibele structuur aan te kunnen bieden.
pi_139730844
quote:
0s.gif Op vrijdag 9 mei 2014 07:55 schreef Light het volgende:

[..]

Waarom geen klantgegevens en transacties in NoSQL?
En Magento en OpenCart bieden nu (voor zover ik weet) geen mogelijkheid om productgegevens in NoSQL op te slaan. In plaats daarvan komen ze met een mega-hoeveelheid tabellen in MySQL om maar een flexibele structuur aan te kunnen bieden.
Omdat je klantegevens en andere business relationeel wilt indelen, en daar ook je queries op kunnen doen, dat gaat je bij noSQL databases niet op een makkelijke manier lukken, daarnaast heeft het ook eigenlijk helemaal niet zoveel zin omdat je juist noSQL gebruikt vanwege performance en losse structuur. Alles kan natuurlijk, maar of het slim is, is een tweede.
🕰️₿🕰️₿🕰️₿🕰️₿🕰️₿🕰️ TikTok next Block
  vrijdag 9 mei 2014 @ 08:52:51 #220
187069 slacker_nl
Sicko pur sang
pi_139730991
In theory there is no difference between theory and practice. In practice there is.
  vrijdag 9 mei 2014 @ 10:12:51 #221
12221 Tijn
Powered by MS Paint
pi_139732436
Het gaat vooral om de eigenachappen van producten waarin je flexibel wilt zijn, toch? Dus waarom niet een column "properties" in de product tabel waar je gewoon JSON in zet? :P
pi_139732516
quote:
0s.gif Op donderdag 8 mei 2014 10:31 schreef raptorix het volgende:

[..]

Naja het is alweer tijd geleden dat ik er wat mee gedaan heb, ik had veel problemen met configuratie onder windows.

Ter voorbeeld, hoe zou je dit in bijvoorbeeld PHP aanpakken?
[ code verwijderd ]

1$colors = preg_grep('~blue~i', $colors);
:+
When the student is ready, the teacher will appear.
When the student is truly ready, the teacher will disappear.
pi_139736636
Nvm , done fixed :). Het komt erop neer dat ik een foutje had gemaakt O+ BUGS ftw. _O- . Eenmalige gelukkig.

[ Bericht 27% gewijzigd door cablegunmaster op 09-05-2014 14:20:44 ]
Redacted
  vrijdag 9 mei 2014 @ 17:49:27 #224
178193 Juicyhil
Bekende FOK!ker
pi_139746633
quote:
6s.gif Op vrijdag 9 mei 2014 10:12 schreef Tijn het volgende:
Het gaat vooral om de eigenachappen van producten waarin je flexibel wilt zijn, toch? Dus waarom niet een column "properties" in de product tabel waar je gewoon JSON in zet? :P
:|W
Op dinsdag 9 augustus 2011 23:01 schreef SuperrrTuxxx het volgende:
Ik hou zoveel van jou, ik doe alles voor je! O+
  vrijdag 9 mei 2014 @ 17:51:32 #225
230788 n8n
Pragmatisch
pi_139746692
quote:
6s.gif Op vrijdag 9 mei 2014 10:12 schreef Tijn het volgende:
Het gaat vooral om de eigenachappen van producten waarin je flexibel wilt zijn, toch? Dus waarom niet een column "properties" in de product tabel waar je gewoon JSON in zet? :P
Gewoon alles met nodejs dit dat
Specialization is for insects”.—Robert Heinlein
pi_139747165
quote:
6s.gif Op vrijdag 9 mei 2014 10:12 schreef Tijn het volgende:
Het gaat vooral om de eigenachappen van producten waarin je flexibel wilt zijn, toch? Dus waarom niet een column "properties" in de product tabel waar je gewoon JSON in zet? :P
:P En daar gaat je normalisatie.
pi_139748135
quote:
19s.gif Op vrijdag 9 mei 2014 18:09 schreef TwenteFC het volgende:

[..]

:P En daar gaat je normalisatie.
Is een middel, geen doel. :)
pi_139748469
quote:
6s.gif Op vrijdag 9 mei 2014 10:12 schreef Tijn het volgende:
Het gaat vooral om de eigenachappen van producten waarin je flexibel wilt zijn, toch? Dus waarom niet een column "properties" in de product tabel waar je gewoon JSON in zet? :P
Of xml opslaan in zo'n blob. ;)
pi_139748711
quote:
0s.gif Op vrijdag 9 mei 2014 08:41 schreef raptorix het volgende:

[..]

Omdat je klantegevens en andere business relationeel wilt indelen, en daar ook je queries op kunnen doen, dat gaat je bij noSQL databases niet op een makkelijke manier lukken, daarnaast heeft het ook eigenlijk helemaal niet zoveel zin omdat je juist noSQL gebruikt vanwege performance en losse structuur. Alles kan natuurlijk, maar of het slim is, is een tweede.
In zo'n situatie moet je voor- en nadelen van beide mogelijkheden uitzoeken tegen elkaar afwegen. Ik vind het wat lastig om bij voorbaat een keuze te maken, maar ik zou niets op voorhand uitsluiten. Er is ook niets mis mee om een deel van de data in NoSQL te zetten en een ander deel in een relationele database. :)
  vrijdag 9 mei 2014 @ 22:36:24 #230
187069 slacker_nl
Sicko pur sang
pi_139759271
quote:
0s.gif Op donderdag 8 mei 2014 10:31 schreef raptorix het volgende:

[..]

Naja het is alweer tijd geleden dat ik er wat mee gedaan heb, ik had veel problemen met configuratie onder windows.

Ter voorbeeld, hoe zou je dit in bijvoorbeeld PHP aanpakken?
[ code verwijderd ]

Tis geen PHP, maar met php moet het ook zo kunnen
1
2
3
4
5
6
7
8
9
10
11
# Perl
@kleurtjes = qw(orange blue darkBlue);
foreach (grep /blue/i, @kleurtjes) { 
    print $_ . $/;
}

# PHP
kleurtjes = [ 'orange', 'blue', 'darkBlue' ] ; 
foreach (preg_grep('/blue/i', $kleurtjes) as $k) {
    print $k . "\n";
}

Zo moeilijk was dat toch niet?
In theory there is no difference between theory and practice. In practice there is.
pi_139864424
Even een simpele moeilijke vraag.

- Bestanden uploaden (controle op php extensie en op inhoud of er mogelijk code instaat )
- (plaatjes met extra code erin bvb ) Is dit mogelijk?
- Hoe ik de folder afscherm van mogelijk gebruik (toch op een manier een php file geupload en deze folder disablen om de php scripts te draaien).

Is dit mogelijk :P ?
Redacted
pi_139864544
Ik zou zeggen, probeer je vraag eerst een keer in begrijpbaar Nederlands te stellen. Dan wordt het voor jezelf waarschijnlijk ook al een stuk duidelijker.
pi_139864613
quote:
14s.gif Op maandag 12 mei 2014 13:34 schreef KomtTijd... het volgende:
Ik zou zeggen, probeer je vraag eerst een keer in begrijpbaar Nederlands te stellen. Dan wordt het voor jezelf waarschijnlijk ook al een stuk duidelijker.
Je hebt vast gelijk :). maar het is al opgelost.
Even rondgevraagd en die oplossing is al gemaakt.
1php_flag engine off

zocht ik :Y
Redacted
pi_139869531
Op mijn ftpserver draait phpversie: 5.3.28
Nu zit ik op de wikipedia te kijken welke versies dat er zijn en zie dat 5.3 t/m juli 2014 ondersteund wordt.
Mijn vraag is nu of het kwaad kan dat mijn server 5.3 heeft en wat eventuele gevolgen kunnen zijn voor mijn website.
  maandag 12 mei 2014 @ 21:08:01 #235
178193 Juicyhil
Bekende FOK!ker
pi_139881481
quote:
5s.gif Op maandag 12 mei 2014 16:10 schreef karton2 het volgende:
Op mijn ftpserver draait phpversie: 5.3.28
Nu zit ik op de wikipedia te kijken welke versies dat er zijn en zie dat 5.3 t/m juli 2014 ondersteund wordt.
Mijn vraag is nu of het kwaad kan dat mijn server 5.3 heeft en wat eventuele gevolgen kunnen zijn voor mijn website.
Het zal niet zo zijn dat je website van de ene op de andere dag kapot gaat :P Maar je wilt het liefst in een productieomgeving wel een ondersteunde versie hebben. Ik noem maar zoiets als een heartblead bug van laatst, dat je wel zeker weet dat er patches worden uitgebracht als er iets mis is.
Dus als het kan zeker upgraden.
Op dinsdag 9 augustus 2011 23:01 schreef SuperrrTuxxx het volgende:
Ik hou zoveel van jou, ik doe alles voor je! O+
  maandag 12 mei 2014 @ 22:39:10 #236
187069 slacker_nl
Sicko pur sang
pi_139886890
quote:
5s.gif Op maandag 12 mei 2014 16:10 schreef karton2 het volgende:
Op mijn ftpserver draait phpversie: 5.3.28
Nu zit ik op de wikipedia te kijken welke versies dat er zijn en zie dat 5.3 t/m juli 2014 ondersteund wordt.
Mijn vraag is nu of het kwaad kan dat mijn server 5.3 heeft en wat eventuele gevolgen kunnen zijn voor mijn website.
Welk OS draai je en hoe zit het met de support daarop? Debian doet bijvoorbeeld gewoon de security patches loslaten op bijv. de 5.3.x branch als ze die leveren.

Is unsupported http://nl3.php.net/releases/, edoch, krijg ik gewoon security fixes binnen.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$ php -v
PHP 5.3.3-7+squeeze19 with Suhosin-Patch (cli) (built: Feb 18 2014 13:59:15) 
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
    with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 6.0.9 (squeeze)
Release:        6.0.9
Codename:       squeeze

gzip -dc /usr/share/doc/php5-common/changelog.Debian.gz | less
php5 (5.3.3-7+squeeze19) squeeze-security; urgency=low

  * [CVE-2014-1943]: Fix segmentation fault in libmagic (Closes: #739012)

 -- Ondřej Surư <ondrej@debian.org>  Mon, 17 Feb 2014 10:52:15 +0100


[ Bericht 49% gewijzigd door slacker_nl op 12-05-2014 22:44:36 ]
In theory there is no difference between theory and practice. In practice there is.
pi_139890033
De 5.3 branch wordt (nu) ook door PHP nog gesupport dus da's niet zo gek.

@karton2: Als het een managed server is, is in principe de hosting partij verantwoordelijk voor je php-installatie. Waarschijnlijk zul je dan binnenkort inderdaad naar 5.4 of 5.5 geslingerd worden. Als je bang bent dat dat je applicaties breekt zou je het vast kunnen testen, maar die kans is niet zo groot hoor. Zeker niet als je een bekend en up-to-date CMS gebruikt.
Als je 'm zelf beheert zou ik gewoon zsm updaten. Nadelen heeft het niet en vroeg of laat zal het toch moeten.
  dinsdag 13 mei 2014 @ 00:08:59 #238
187069 slacker_nl
Sicko pur sang
pi_139891591
quote:
14s.gif Op maandag 12 mei 2014 23:34 schreef KomtTijd... het volgende:
De 5.3 branch wordt (nu) ook door PHP nog gesupport dus da's niet zo gek.

@karton2: Als het een managed server is, is in principe de hosting partij verantwoordelijk voor je php-installatie. Waarschijnlijk zul je dan binnenkort inderdaad naar 5.4 of 5.5 geslingerd worden. Als je bang bent dat dat je applicaties breekt zou je het vast kunnen testen, maar die kans is niet zo groot hoor. Zeker niet als je een bekend en up-to-date CMS gebruikt.
Als je 'm zelf beheert zou ik gewoon zsm updaten. Nadelen heeft het niet en vroeg of laat zal het toch moeten.
Alleen 5.3.28 als ik http://nl3.php.net/downloads.php erbij pak. en de pagina waar 5.3.3 op staat zegt:
quote:
Unsupported Historical Releases

We have collected all the official information and code available for past PHP releases.
In theory there is no difference between theory and practice. In practice there is.
pi_139895174
quote:
0s.gif Op dinsdag 13 mei 2014 00:08 schreef slacker_nl het volgende:

[..]

Alleen 5.3.28 als ik http://nl3.php.net/downloads.php erbij pak. en de pagina waar 5.3.3 op staat zegt:

[..]

Bugfixes worden door Debian gebackport, waardoor je wel altijd op de versie blijft die meegeleverd werd in de distro. Daarom ook zie je PHP 5.3.3-7+squeeze19 staan als versienummer. En zolang Debian 6.0 ondersteund wordt (tot feb 2016 voor i386 en amd64) zullen ze die bugfixes blijven doen (tenzij ze expliciet aangeven dat niet te doen, er is/komt een tooltje om packages te vinden die niet meer ondersteund worden).
  dinsdag 13 mei 2014 @ 12:33:24 #240
187069 slacker_nl
Sicko pur sang
pi_139901289
quote:
0s.gif Op dinsdag 13 mei 2014 08:25 schreef Light het volgende:

[..]

Bugfixes worden door Debian gebackport, waardoor je wel altijd op de versie blijft die meegeleverd werd in de distro. Daarom ook zie je PHP 5.3.3-7+squeeze19 staan als versienummer. En zolang Debian 6.0 ondersteund wordt (tot feb 2016 voor i386 en amd64) zullen ze die bugfixes blijven doen (tenzij ze expliciet aangeven dat niet te doen, er is/komt een tooltje om packages te vinden die niet meer ondersteund worden).
Dat zei ik toch ook in m'n allereerste reactie :)
In theory there is no difference between theory and practice. In practice there is.
abonnement Unibet Coolblue Bitvavo
Forum Opties
Forumhop:
Hop naar:
(afkorting, bv 'KLB')