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....quote:Op woensdag 7 mei 2014 18:18 schreef TwenteFC het volgende:
[..]Je doet alsof een webshop een heel gecompliceerd iets is, dat valt ook wel weer mee.
Je hebt alleen flexibiliteit nodig om al die seo meuk handelbaar te houden op een lange termijn.
Yep, ik heb nu ook 2 shops in Magento moeten maken, het is ook best wel bagger.quote:Op woensdag 7 mei 2014 10:58 schreef raptorix het volgende:
[..]
Waarom je uberhaupt Magento zou gebruiken is me een raadsel, ik heb het ooit wel eens bekeken, wat een bagger zeg, alleen al de honderden zo niet duizenden files waarmee je te maken hebt.
Veel tabellen zegt niet alles, maar 348 is idioot, ik heb ooit in 1999 mijn eigen webshop geschreven die vrij uitgebreid was, en toen kwam ik volgens mij op een tabel of 25, overigens ook wel eens met een database gewerkt van boven de 1000 tablesquote:Op donderdag 8 mei 2014 08:11 schreef mstx het volgende:
[..]
Yep, ik heb nu ook 2 shops in Magento moeten maken, het is ook best wel bagger.![]()
En dan heb je waarschijnlijk nog niet naar de database gekeken, een standaardinstallatie heeft 348 (!!!) tabellen.Je kan ook niet even een simpel importscriptje voor producten ofzo schrijven want dan moet je dus in superveel tabellen shit wegschrijven.
Ik mag toch hopen dat er goede documentatie beschikbaar was voor dat monster. Het grootste aantal tables dat ik ooit heb gezien zal ergens rond de 100 liggen. De documentatie was helaas erg beperkt en ik moest zelf uit gaan zoeken welke tables met elkaar te linken waren en op welke velden. Velden hadden, om het nog erger te maken, veelal onduidelijke namen wat dit gedoe er niet makkelijker op maakte. Heeft me erg veel tijd gekost om dat ding in kaart te brengen en alsnog te beschrijven.quote:Op donderdag 8 mei 2014 08:12 schreef raptorix het volgende:
[..]
overigens ook wel eens met een database gewerkt van boven de 1000 tables
Dit was de global product database van Ericson, zat op zich goed en logisch in elkaar, maar alles wat ook maar bekend was qua producten van Ericsson zat in dat ding, opzich als je gewend bent met complexe databases kom je er best goed uit, zaten wel wat vervelende dingen in, omdat zoveel applicaties er van gebruik maakten was men heel huiverig op changes, dus maakte men al snel weer een nieuw table aan. Zo waren er een stuk of 8 tables met regions/landen wat het niet echt mooi maakte.quote:Op donderdag 8 mei 2014 08:23 schreef bondage het volgende:
[..]
Ik mag toch hopen dat er goede documentatie beschikbaar was voor dat monster. Het grootste aantal tables dat ik ooit heb gezien zal ergens rond de 100 liggen. De documentatie was helaas erg beperkt en ik moest zelf uit gaan zoeken welke tables met elkaar te linken waren en op welke velden. Velden hadden, om het nog erger te maken, veelal onduidelijke namen wat dit gedoe er niet makkelijker op maakte. Heeft me erg veel tijd gekost om dat ding in kaart te brengen en alsnog te beschrijven.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | oc_product oc_product_attribute oc_product_description oc_product_discount oc_product_filter oc_product_image oc_product_option oc_product_option_value oc_product_profile oc_product_recurring oc_product_related oc_product_reward oc_product_special oc_product_to_category oc_product_to_download oc_product_to_layout oc_product_to_store |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 | catalog_product_bundle_option catalog_product_bundle_option_value catalog_product_bundle_price_index catalog_product_bundle_selection catalog_product_bundle_selection_price catalog_product_bundle_stock_index catalog_product_enabled_index catalog_product_entity catalog_product_entity_datetime catalog_product_entity_decimal catalog_product_entity_gallery catalog_product_entity_group_price catalog_product_entity_int catalog_product_entity_media_gallery catalog_product_entity_media_gallery_value catalog_product_entity_text catalog_product_entity_tier_price catalog_product_entity_varchar catalog_product_flat_1 catalog_product_index_eav catalog_product_index_eav_decimal catalog_product_index_eav_decimal_idx catalog_product_index_eav_decimal_tmp catalog_product_index_eav_idx catalog_product_index_eav_tmp catalog_product_index_group_price catalog_product_index_price catalog_product_index_price_bundle_idx catalog_product_index_price_bundle_opt_idx catalog_product_index_price_bundle_opt_tmp catalog_product_index_price_bundle_sel_idx catalog_product_index_price_bundle_sel_tmp catalog_product_index_price_bundle_tmp catalog_product_index_price_cfg_opt_agr_idx catalog_product_index_price_cfg_opt_agr_tmp catalog_product_index_price_cfg_opt_idx catalog_product_index_price_cfg_opt_tmp catalog_product_index_price_downlod_idx catalog_product_index_price_downlod_tmp catalog_product_index_price_final_idx catalog_product_index_price_final_tmp catalog_product_index_price_idx catalog_product_index_price_opt_agr_idx catalog_product_index_price_opt_agr_tmp catalog_product_index_price_opt_idx catalog_product_index_price_opt_tmp catalog_product_index_price_tmp catalog_product_index_tier_price catalog_product_index_website catalog_product_link catalog_product_link_attribute catalog_product_link_attribute_decimal catalog_product_link_attribute_int catalog_product_link_attribute_varchar catalog_product_link_type catalog_product_option catalog_product_option_price catalog_product_option_title catalog_product_option_type_price catalog_product_option_type_title catalog_product_option_type_value catalog_product_relation catalog_product_super_attribute catalog_product_super_attribute_label catalog_product_super_attribute_pricing catalog_product_super_link |
Ik snap niet dat jij zegt dat een goede webshop niet in een halfjaar te bouwen is, weet niet op welk slakken tempo jij typt, maar beetje webshop valt ECHT wel in een halfjaar te ontwikkelen. Maar goed, voor de ene is goed goed en de ander slecht!quote:Op donderdag 8 mei 2014 08:00 schreef raptorix het volgende:
[..]
Wat snap je niet aan een goede webshop?
Natuurlijk kun je wel een webshop bouwen in een halfjaar, maar we hadden het over een goede webshop, maar mijn punt blijft dat het onzin is om zelf webshops te gaan bouwen, verspilling van tijd en geld, want het loont gewoon niet, er zijn zat prima producten op de markt waarbij men 10.000 uren heeft geinvesteerd om het te optimaliseren, daar kan je gewoon niet tegen op werken.quote:Op donderdag 8 mei 2014 08:51 schreef Chandler het volgende:
[..]
Ik snap niet dat jij zegt dat een goede webshop niet in een halfjaar te bouwen is, weet niet op welk slakken tempo jij typt, maar beetje webshop valt ECHT wel in een halfjaar te ontwikkelen. Maar goed, voor de ene is goed goed en de ander slecht!
Oh en je zegt dat jullie met 10 man werken, mooi man, zal wel een extreem uitgebreid product zijn, met bergen met opties etc.. wat een gemiddelde webshop dus niet nodig heeft, lijkt mij.
En als jij zegt dat 99% niet goed is, zowww dan kunnen we beter maar stoppen met internetten want er zijn zoveel webshops geschreven door 1 persoon, die zijn dus bij deze allemaal uitermate slecht..
De functionaliteit van een webshop is snel te maken. Tis een CMS met een Ogone koppeling. Echter heb je ook te maken met wat werkt prettig voor de gebruiker. Alles is te maken. Maar ben het met raptor eens dat je ook flink moet investeren in je product als je een goede bruikbare shop wilt hebben. Werkende prototypes zijn een, goed werkende eindproducten zijn een ander verhaal.quote:Op woensdag 7 mei 2014 18:18 schreef TwenteFC het volgende:
[..]Je doet alsof een webshop een heel gecompliceerd iets is, dat valt ook wel weer mee.
Je hebt alleen flexibiliteit nodig om al die seo meuk handelbaar te houden op een lange termijn.
Is het absoluut geen onzin, als iedereen dacht zoals jij zaten we nog steeds te internetten op een modem en moesten we downloaden vanaf bbsjes...quote:Op donderdag 8 mei 2014 08:57 schreef raptorix het volgende:
Natuurlijk kun je wel een webshop bouwen in een halfjaar, maar we hadden het over een goede webshop, maar mijn punt blijft dat het onzin is om zelf webshops te gaan bouwen, verspilling van tijd en geld, want het loont gewoon niet, er zijn zat prima producten op de markt waarbij men 10.000 uren heeft geïnvesteerd om het te optimaliseren, daar kan je gewoon niet tegen op werken.
Ik ben het ook met je eens, maar meeste webshops hoeven geen detail tree, of bergen met opties, die willen producten aanbieden om te verkopen, met betaal mogelijkheid, klanten database... je kunt het jezelf zo moeilijk maken als je zelf wilt, maar het is in mijn ogen de uitdaging om het allemaal zelf te schrijven.quote:Op donderdag 8 mei 2014 08:58 schreef slacker_nl het volgende:
De functionaliteit van een webshop is snel te maken. Tis een CMS met een Ogone koppeling. Echter heb ook te maken met wat werkt prettig voor de gebruiker. Alles is te maken. Maar ben het met raptor eens dat je ook flink moet investeren in je product als je een goede bruikbare shop wilt hebben. Werkende prototypes zijn een, goed werkende eindproducten zijn een ander verhaal.
quote:
Staat op hun site.quote:nopCommerce is a fully customizable shopping cart. It's stable and highly usable. nopCommerce is an open source ecommerce solution that is ASP.NET (MVC) based with a MS SQL 2008 (or higher) backend database.
ASP.NET uses the multi-language abilities of the .NET Common Language Runtime, allowing Web pages to be coded in VB.NET, C#, J#, Delphi.NET, Chrome, etc.quote:
Iets doen omdat je het leuk vind of om te leren is heel wat anders dan professioneel een site ontwikkelen, daarnaast kan ik zeggen dat ik juist heel erg voor vooruitgang ben, en daarom liever nieuwe dingen ontwikkel dan het wiel opnieuw uitvinden.quote:Op donderdag 8 mei 2014 09:07 schreef Chandler het volgende:
[..]
Is het absoluut geen onzin, als iedereen dacht zoals jij zaten we nog steeds te internetten op een modem en moesten we downloaden vanaf bbsjes...
Juist doordat mensen zelf dingen proberen te maken leert men, kijkt men dingen van elkaar af. Ik heb zat sites ontwikkeld die NOOIT het daglicht hebben gezien, waarom, onvrede van mijn kant over het product wat ik had gemaakt, niet goed genoeg, maar heb ook zat sites wel afgemaakt die ik zo kon 'kopen' ipv zelf te schrijven, maar juist het zelf schrijven is vaak veel leuker dan het moeten werken met bv magento/wordpress/etc.
Het is jou mening dat het verspilling van geld en tijd is, ik verspeel ook veel tijd met vissen, uren aan de waterkant en totaal NIETS doen... god wat een verspilling van 'energie en geld'.. maar ik geniet er wel op en top van, leer iedere keer wat... dat heb je niet als je dingen gaat toevoegen aan bestaande producten, je hebt geen flauw idee wat er allemaal in het systeem gebeurd, hebt weinig controle over plus je leert niet hoe het allemaal in elkaar zit. Ik snap best dat je kiest voor pakketten die al bestaan, maar snap niet dat je het afraad om het zelf te maken.. zeg maar..
[..]
Ik ben het ook met je eens, maar meeste webshops hoeven geen detail tree, of bergen met opties, die willen producten aanbieden om te verkopen, met betaal mogelijkheid, klanten database... je kunt het jezelf zo moeilijk maken als je zelf wilt, maar het is in mijn ogen de uitdaging om het allemaal zelf te schrijven.
Daarom zie je ook bergen met mensen zelf blogs schrijven, vroeger gastenboeken etc maken... waarom? omdat het leuk is om het zelf te doen.. ipv iets te gebruiken wat van een ander is.
ASP is niet te vergelijken met ASP.NET , ongeveer zelfde om java te vergelijken met javascript.quote:
Het probleem met inhouse ontwikkelen is dat je een product aan het maken bent, dat is een compleet andere tak van sport dan het verlenen van een dienst.quote:Op donderdag 8 mei 2014 10:07 schreef KomtTijd... het volgende:
Het kan nog wel eens vies tegenvallen wat er aan 'goede' webshops op de markt is. Veel van ditsoort producten zijn ofwel proprietary met alle beperkingen van dien, ofwel van moeilijk belabberde kwaliteit. Als je echt een op maat gesneden oplossing zoekt, is beiden vaak geen optie en is inhouse ontwikkelen vaak echt de beste keus.
Het gaat erom wat het nut is, ik denk dat het veel nuttiger is om nieuwe features van bijvoorbeeld een opensource project te ontwikkelen, profiteren ook nog meer mensen van.quote:Op donderdag 8 mei 2014 10:12 schreef Chandler het volgende:
Dan denken we niet hetzelfde, dat kan hoorik zou het liefst het wiel opnieuw uitvinden, is veel stoerder dan de spaken poetsen!
![]()
Allebei meuk, dus prima te vergelijken.quote:Op donderdag 8 mei 2014 10:11 schreef raptorix het volgende:
[..]
ASP is niet te vergelijken met ASP.NET , ongeveer zelfde om java te vergelijken met javascript.
Naja, laat ik niet gaan bashen in het PHP topicquote:Op donderdag 8 mei 2014 10:14 schreef Boze_Appel het volgende:
[..]
Allebei meuk, dus prima te vergelijken.
Ik heb gewoon slechte ervaringen met PHP, nu zal ik de laatste zijn die zal beweren dat er slechte talen zijn, want zelfs in een goede taal kun je slecht programmeren, maar ik vind het in PHP gewoon omslachtig, probeer maar eens c# in visual studio met Resharper en er zal een wereld voor je open gaan.quote:Op donderdag 8 mei 2014 10:19 schreef Chandler het volgende:
Wees vrij rap, tis hier toch meer slowchat... dan praten over 'php op zich'
Mja ik ben zelf bezig met het inhouse ontwikkelen van een CRM systeem. Na een jaar gekut met een open-source CRM systeem (Vtiger) ben ik wel enigszins teruggekomen op deze mening.quote:Op donderdag 8 mei 2014 10:13 schreef raptorix het volgende:
[..]
Het gaat erom wat het nut is, ik denk dat het veel nuttiger is om nieuwe features van bijvoorbeeld een opensource project te ontwikkelen, profiteren ook nog meer mensen van.
Wel eens gekeken naar Salesforce (niet opensource) maar wel zeer betaalbaar.quote:Op donderdag 8 mei 2014 10:23 schreef KomtTijd... het volgende:
[..]
Mja ik ben zelf bezig met het inhouse ontwikkelen van een CRM systeem. Na een jaar gekut met een open-source CRM systeem (Vtiger) ben ik wel enigszins teruggekomen op deze mening.
OS-producten gebruiken is alleen nuttig als er ook daadwerkelijk iets beschikbaar is wat een goeie basis heeft, en dat is lang niet altijd het geval.
+1 maar wat voor slechte ervaringen dan? maar C, C++, C# is niet mijn ding, nooit iets mee gedaan en zal het ws ook nooit gaan doen... php/python vind ik wel erg leuk, vooral nu Python omdat het lijkt op PHP maar toch compleet anders isquote:Op donderdag 8 mei 2014 10:22 schreef raptorix het volgende:
Ik heb gewoon slechte ervaringen met PHP, nu zal ik de laatste zijn die zal beweren dat er slechte talen zijn, want zelfs in een goede taal kun je slecht programmeren, maar ik vind het in PHP gewoon omslachtig, probeer maar eens c# in visual studio met Resharper en er zal een wereld voor je open gaan.
Naja het is alweer tijd geleden dat ik er wat mee gedaan heb, ik had veel problemen met configuratie onder windows.quote:Op donderdag 8 mei 2014 10:26 schreef Chandler het volgende:
[..]
+1 maar wat voor slechte ervaringen dan? maar C, C++, C# is niet mijn ding, nooit iets mee gedaan en zal het ws ook nooit gaan doen... php/python vind ik wel erg leuk, vooral nu Python omdat het lijkt op PHP maar toch compleet anders is
1 2 3 4 5 | string[] colors = Enum.GetNames(typeof(System.Drawing.KnownColor)); foreach (string color in colors.Where(c => c.ToLower().Contains("blue"))) { Console.WriteLine(color); } |
Je hebt een lijst met kleuren en wilt alle kleuren zien die blauw in hun naam hebben ofzo?quote: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 2 3 4 5 6 7 | <?php foreach ($lijstmetKleuren as $k=>$v) { if (strpos(strtolower($v),"blue") > 0) { // gevonden } } ?> |
Dat vind ik echt zo heerlijk met Linq, vrij complexe zaken kun je op prachtige manieren shortcutten.quote:Op donderdag 8 mei 2014 10:40 schreef Chandler het volgende:
ok
[ code verwijderd ]
Jammere van PHP is dat de ene keer je string, zoekwoord hebt en de andere keer zoekwoord, string
zo omslachtig is't nietmaar moet zeggen dat ik het puntjes systeem van Python heerlijk vind .toLower().find('lol') etc
Maar juist shortcutten kan er ook voor zorgen dat de code onleesbaar wordt als het slecht is geprogrammeerdquote:Op donderdag 8 mei 2014 10:47 schreef raptorix het volgende:
[..]
Dat vind ik echt zo heerlijk met Linq, vrij complexe zaken kun je op prachtige manieren shortcutten.
Uiteraard, je moet het niet overdrijven.quote:Op donderdag 8 mei 2014 10:48 schreef Rockfire het volgende:
[..]
Maar juist shortcutten kan er ook voor zorgen dat de code onleesbaar wordt als het slecht is geprogrammeerd
1 2 3 4 5 6 7 8 9 10 11 | decimal total = new decimal(); decimal petesTotalNumberOfRolls = petes.Sum(x => x.Value); decimal colinsTotalNumberOfRolls = colins.Sum(x => x.Value); foreach (KeyValuePair<int, int> kvpPetes in petes) { decimal colinsNumberOfThrows = colins.Where(x => x.Key < kvpPetes.Key).Sum(x => x.Value); decimal petesNumberOfThrows = kvpPetes.Value; total = total + ((petesNumberOfThrows / petesTotalNumberOfRolls) * (colinsNumberOfThrows / colinsTotalNumberOfRolls)); } |
Strpos geeft de positie van de gevonden string terug, dus dat kan ook 0 zijn. Om te weten of-ie gevonden is, kun je beter een sterke comparison doen met false (dus === false voor niet en !== false voor wel gevonden). En als je stripos() gevruikt, is toLower() niet nodigquote:Op donderdag 8 mei 2014 10:40 schreef Chandler het volgende:
ok
[ code verwijderd ]
Jammere van PHP is dat de ene keer je string, zoekwoord hebt en de andere keer zoekwoord, string
zo omslachtig is't nietmaar moet zeggen dat ik het puntjes systeem van Python heerlijk vind .toLower().find('lol') etc
Ook voorbeelden moeten kloppen, je weet nooit wat iemand copy-paste en in z'n applicatie stopt.quote:Op donderdag 8 mei 2014 10:53 schreef Chandler het volgende:
Klopt Tijn, !== moest het zijn maar dan nog, ging even snel om het voorbeeld
Je zou bijvoorbeeld in PHP een library kunnen oproepen met daarin de kleuren. Maar voor de overzichtelijkheid, stop ik de kleuren in een array.quote:Op donderdag 8 mei 2014 10:53 schreef Tijn het volgende:
[..]
Strpos geeft de positie van de gevonden string terug, dus dat kan ook 0 zijn. Om te weten of-ie gevonden is, kun je beter een sterke comparison doen met false (dus === false voor niet en !== false voor wel gevonden). En als je stripos() gevruikt, is toLower() niet nodig
1 2 3 4 | $colors = array("red", "blue", "yellow"); if $(in_array("blue", $colors) { echo array_search("blue", $colors); } |
Juistquote:Op donderdag 8 mei 2014 10:55 schreef Tijn het volgende:
[..]
Ook voorbeelden moeten kloppen, je weet nooit wat iemand copy-paste en in z'n applicatie stopt.
SPOILEROm spoilers te kunnen lezen moet je zijn ingelogd. Je moet je daarvoor eerst gratis Registreren. Ook kun je spoilers niet lezen als je een ban hebt.The people who lost my respect will never get a capital letter for their name again.
Like trump...
Het punt is dat het niet native in je framework zit, ben wel benieuwd naar de performance op wat grotere collecties.quote:Op donderdag 8 mei 2014 10:59 schreef Tijn het volgende:
Sowieso is Linq natuurlijk gewoon te implementeren in PHP, als je het echt zo graag zou willen gebruiken
Er zijn meerdere libraries te vinden die je zo kunt toepassen, zoals http://phplinq.codeplex.com
In PHP kun je ook gewoon methods chainen...quote:Op donderdag 8 mei 2014 10:47 schreef raptorix het volgende:
[..]
Dat vind ik echt zo heerlijk met Linq, vrij complexe zaken kun je op prachtige manieren shortcutten.
Tsja, geen idee natuurlijk. Maar ook dan is er vast wel iets te bedenken om het wel te laten performen lijkt mequote:Op donderdag 8 mei 2014 11:01 schreef raptorix het volgende:
[..]
Het punt is dat het niet native in je framework zit, ben wel benieuwd naar de performance op wat grotere collecties.
Meh, zal al snel net zo duur zijn als dat ik ben, plus dan moet ik er nog steeds tegenaan ontwikkelen. Voor zover dat uberhaupt mag.quote:Op donderdag 8 mei 2014 10:24 schreef raptorix het volgende:
[..]
Wel eens gekeken naar Salesforce (niet opensource) maar wel zeer betaalbaar.
Vooral op lange termijn is in-house natuurlijk veel goedkoper, als je het goed doet. Voor zo'n Salesforce mag je voor een klein team al snel 30K per jaar neerleggen, dus als je dat 10 jaar gebruikt heb je 3 ton verbrand.quote:Op donderdag 8 mei 2014 11:05 schreef KomtTijd... het volgende:
[..]
Meh, zal al snel net zo duur zijn als dat ik ben, plus dan moet ik er nog steeds tegenaan ontwikkelen. Voor zover dat uberhaupt mag.
Voorbeeldje?quote:Op donderdag 8 mei 2014 11:01 schreef Sitethief het volgende:
[..]
In PHP kun je ook gewoon methods chainen...
PDO bijvoorbeeld:quote:
1 2 3 | <?php $row = $db->query('SELECT * FROM `example`')->fetch(); ?> |
Kan, maar ik zou juist dit los van elkaar willen ivm fouten etcquote:Op donderdag 8 mei 2014 11:19 schreef Tijn het volgende:
PDO bijvoorbeeld:
[ code verwijderd ]
Je kunt dit ook heel makkelijk met je eigen classes doen, het is gewoon een kwestie van de methodes zichzelf laten returnen.
Valt juist erg mee, daarnaast is Salesforce perfect om aan te sluiten op je maatwerk omdat je direct een SOAP interface kunt genereren, ik had het binnen een dag aangesloten op een bestaand CMS voor een woningcorporatie.quote:Op donderdag 8 mei 2014 11:11 schreef Tijn het volgende:
[..]
Vooral op lange termijn is in-house natuurlijk veel goedkoper, als je het goed doet. Voor zo'n Salesforce mag je voor een klein team al snel 30K per jaar neerleggen, dus als je dat 10 jaar gebruikt heb je 3 ton verbrand.
Mwah, 135,- euro per gebruiker per jaar is met een klein clubje van 20 man toch een slordige 32.400 euro, toch?quote:
Ga jij maar een maatwerk CRM systeem maken voor een club van 20 man, en ga het ook maar eens supporten en onderhouden de komende 10 jaar. Het is algemeen bekend dat het bouwen van maatwerk nooit opweegt tegen licentie kosten.quote:Op donderdag 8 mei 2014 11:28 schreef Tijn het volgende:
[..]
Mwah, 135,- euro per gebruiker per jaar is met een klein clubje van 20 man toch een slordige 32.400 euro, toch?
Zal ongetwijfeld in de meeste gevallen zo zijn, maar dan nog is het erg duur, ongetwijfeld nog duurder als je het zelf gaat ontwikkelen maar goed...quote:Op donderdag 8 mei 2014 11:29 schreef raptorix het volgende:
Ga jij maar een maatwerk CRM systeem maken voor een club van 20 man, en ga het ook maar eens supporten en onderhouden de komende 10 jaar. Het is algemeen bekend dat het bouwen van maatwerk nooit opweegt tegen licentie kosten.
Ik doe dat al. Eenmalig is het een investering voor zo'n club, maar daarna zijn de kosten per jaar om het in de lucht te houden veel lager, waarop het op termijn zichzelf makkelijk terugbetaalt voor een organisatie.quote:Op donderdag 8 mei 2014 11:29 schreef raptorix het volgende:
[..]
Ga jij maar een maatwerk CRM systeem maken voor een club van 20 man, en ga het ook maar eens supporten en onderhouden de komende 10 jaar. Het is algemeen bekend dat het bouwen van maatwerk nooit opweegt tegen licentie kosten.
Ik denk niet dat jouw productje ook maar in de buurt komt wat Salesforce bied.quote:Op donderdag 8 mei 2014 11:32 schreef Tijn het volgende:
[..]
Ik doe dat al. Eenmalig is het een investering voor zo'n club, maar daarna zijn de kosten per jaar om het in de lucht te houden veel lager, waarop het op termijn zichzelf makkelijk terugbetaalt voor een organisatie.
Nee, zeker niet. Ik denk ook wel dat er organisaties zijn waarvoor zoiets als Salesforce een goede uitkomst is, hoor. Maar ik zie een heleboel simpele, kleine clubs in Nederland waar minder dan 30 mensen werken die wel behoefte hebben aan IT, maar niet aan heel uitgebreide systemen. Die willen gewoon een telefoongesprekje invoeren op een webpagina zodat hun collega's ervan op de hoogte zijn of een reminder krijgen 2 maanden voordat een abonnement van een klant afloopt en that's it. Voor zulke simpele eisen is een maatwerkoplossing helemaal geen gek idee, want dan heb je nauwelijks lopende kosten.quote:Op donderdag 8 mei 2014 11:43 schreef raptorix het volgende:
[..]
Ik denk niet dat jouw productje ook maar in de buurt komt wat Salesforce bied.
Oh daar ben ik wel mee eens, ik had het meer over wat uitgebreide CRM oplossingen. Het punt wat ik wil maken is dat je je organisatie moet inrichten op product ontwikkeling, en dat dat een hele andere tak van sport is.quote:Op donderdag 8 mei 2014 11:47 schreef Tijn het volgende:
[..]
Nee, zeker niet. Ik denk ook wel dat er organisaties zijn waarvoor zoiets als Salfesforce een goede uitkomst is, hoor. Maar ik zie een heleboel simpele, kleine clubs in Nederland waar minder dan 30 mensen werken die wel behoefte hebben aan IT, maar niet aan heel uitgebreide systemen. Die willen gewoon een telefoongesprekje invoeren op een webpagina zodat hun collega's ervan op de hoogte zijn of een reminder krijgen 2 maanden voordat een abonnement van een klant afloopt en that's it. Voor zulke simpele eisen is een maatwerkoplossing helemaal geen gek idee, want dan heb je nauwelijks lopende kosten.
Ik weet ook niet of het slim is om het écht in-house te doen als je geen IT-bedrijf bent. Ik zou denken dat bedrijven zich beter kunnen richten op hun core business en voor IT-maatwerk eenmalig een bureau of een competente freelancer kunnen inschakelen.quote:Op donderdag 8 mei 2014 11:54 schreef raptorix het volgende:
[..]
Het punt wat ik wil maken is dat je je organisatie moet inrichten op product ontwikkeling, en dat dat een hele andere tak van sport is.
Dat is wel waar we hier aan zouden zitten ja.quote:Op donderdag 8 mei 2014 11:28 schreef Tijn het volgende:
[..]
Mwah, 135,- euro per gebruiker per jaar is met een klein clubje van 20 man toch een slordige 32.400 euro, toch?
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.quote:Op donderdag 8 mei 2014 11:43 schreef raptorix het volgende:
[..]
Ik denk niet dat jouw productje ook maar in de buurt komt wat Salesforce bied.
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.quote: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.
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.quote: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.
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.quote: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.
"met mensen als jou"quote: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.
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.quote: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 ]
Op die manier doorzoek je de array wel twee keer, eerst voor in_array en daarna voor array_search.quote: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 ]
1 2 3 4 5 6 7 | <?php $colors = array("red", "blue", "yellow"); $index = array_search('blue', $colors); if ($index !== false) { echo $index; } ?> |
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.quote: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.
Waarom geen klantgegevens en transacties in NoSQL?quote: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.
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.quote: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.
quote: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); |
quote: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?
Gewoon alles met nodejs dit datquote: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?
Forum Opties | |
---|---|
Forumhop: | |
Hop naar: |