Het wiel opnieuw uitvinden

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Danny Spinhuis

Danny Spinhuis

24/03/2018 06:20:10
Quote Anchor link
Dag allemaal,

ik ben voor een onderzoek een stuk aan het schrijven, waarin ik uitleg waarom een bestaande (PHP) oplossing gebruiken en evt. aanpassen voordeliger is dat compleet opnieuw het wiel uit te vinden. In mijn geval staat de PHP oplossing op een externe server, dus ik kan ook evt. iets zeggen dat het qua server processing op eigen server scheelt?

Dat het wiel opnieuw uitvinden veel tijdrovender spreekt voor zich, maar ik kan even niet op andere (technische) punten komen. Heeft iemand wat suggesties?

Ook nadelen zijn welkom.

Dank!
Gewijzigd op 24/03/2018 06:24:13 door Danny Spinhuis
 
PHP hulp

PHP hulp

29/03/2024 06:26:09
 
Rob Doemaarwat

Rob Doemaarwat

24/03/2018 09:49:56
Quote Anchor link
Als de "oplossing" op een externe server staat is aanpassen meestal niet meer mogelijk (tenzij die"externe server" van jezelf is, maar dan is het niet echt meer een externe server).

Meestal wordt een externe service continue voor je onderhouden (updates, systeembeheer, enz). Dat is een voordeel. Het nadeel is dat je meestal ook met updates "mee moet" (binnen 30 dagen even je hele interfacing omgooien ...). Of de stekker gaat er helemaal uit, en je moet van de een op de andere dag een andere "provider" zoeken.

Een externe oplossing hoeft niet perse veiliger te zijn. Als het open source is kun je in ieder geval nog een audit doen, maar dat is wel een enorme uitkam klus.

Het wiel opnieuw uitvinden is wel een hele klus (uren - tijd die je misschien niet hebt binnen je planning), maar het voordeel is dat je meteen alle ins en outs kent, het precies doet wat jij wilt (nu en in de toekomst), en je weer bakken met ervaring+kennis opdoet.
 
Ward van der Put
Moderator

Ward van der Put

24/03/2018 09:51:37
Quote Anchor link
Je moet het onderzoek nog uitvoeren maar je weet nu al wat de uitkomst moet zijn?

Als je wilt bewijzen dat iets voordeliger is, ligt het voor de hand om eerst eens de kosten in kaart te brengen, niet de technische (on) mogelijkheden.
 
John D

John D

24/03/2018 11:09:39
Quote Anchor link
Er zijn in de markt grofweg een drietal sporen: 1) complete nieuwbouw, 2) gebruik en customizen van bestaande applicaties en 3) nieuwbouw op basis van hergebruik van objecten uit de markt. In het MKB zie veelal 1) complete nieuwbouw van kleine applicaties. In de groot zakelijke markt veelal 2) gebruik en customizen van bestaande applicaties. Deze methodiek vindt ook zijn weg al naar het MKB en de hobbymarkt, denk hierbij aan Wordpress, Drubal en dergelijke. 3) hergebruik van objecten uit de markt kom je in de grootzakelijke markt ook tegen en dan voornamelijk in de JAVA driven applicaties (niet javascript) met NODEJS, BEA, JBOSS en dergelijke. In PHP zie ik minder uitwisseling/hergebruik van losse universele objecten alhoewel object oriented ook zijn weg in PHP heeft wel gevonden. Kortom, zoals Ward ook al stelt: Onderzoek is nodig om de kosten in kaart te brengen en dat zal voornamelijk afhankelijk zijn van de toepassing. Wat kan je uit de markt halen en wat moet je zelf bouwen?

Het wiel opnieuw uitvinden hoeft echt niet tijdrovender te zijn en spreekt dus NIET voor zich. Ervaren developers hergebruiken veel eigen code en kunnen doorgaans snel een nieuwe toepassing ontwerpen en bouwen. Minder ervaren bouwers juist niet omdat vaak meteen aan het toetsenbord begonnen wordt met verzinnen en inkloppen van (php)code zonder een gedegen ontwerp. Wellicht is dat wat je bedoelt met "steeds opnieuw het wiel uitvinden"
Gewijzigd op 24/03/2018 11:21:44 door John D
 
Ozzie PHP

Ozzie PHP

24/03/2018 16:19:09
Quote Anchor link
>> In mijn geval staat de PHP oplossing op een externe server, dus ik kan ook evt. iets zeggen dat het qua server processing op eigen server scheelt?

In welk opzicht zou dat een voordeel moeten zijn? Wat nu als die externe server een tragere processor heeft, of er op enig ogenblik volledig mee uitscheidt?

Een php-oplossing gebruiken op een externe server (ik neem aan dat je bedoelt een server waar je zelf geen invloed op hebt) lijkt me niet bepaald een voordeel. En wat als die server niet goed beveiligd blijkt te zijn en bijv. gegevens van klanten daardoor bij hackers terechtkomen?

Overigens is het een beetje vaag wat je precies bedoelt. Er zijn natuurlijk ook echt wel goede API's van erkende bedrijven die je kunt gebruiken, maar ik weet niet of dat is wat je bedoelt.
 
Danny Spinhuis

Danny Spinhuis

24/03/2018 16:24:44
Quote Anchor link
Dank jullie voor alle reacties! Ik heb een beetje slecht uitgelegd merk ik. Wat ik eigenlijk bedoelde:

Ik moest in 3 maanden tijd een oplossing vinden voor een probleem. Ik heb een extensie gevonden (Hypothesis) die aan 90% van de requirements voldoet, de overige 10% heb ik zelf geprogrammeerd. De extensie kun je simpelweg embedden in je website, waardoor het 1 geheel wordt alleen draait de extensie op de externe server van Hypothesis.

Als ik het idee achter Hypothesis zelf zou moeten programmeren zou ik een jaar bezig zijn denk ik. Vandaar dat ik voor de extensie heb gekozen.
 
Ozzie PHP

Ozzie PHP

24/03/2018 16:29:38
Quote Anchor link
Het feit dat die extensie op een externe server draait zou ik niet per definitie een voordeel noemen. Het feit dat je ontwikkeltijd hebt bespaard is wel een voordeel. Daar staat dan weer tegenover dat je afhankelijk bent van die externe server, en de mensen die die server onderhouden, of jouw applicatie blijft werken. Op het moment dat zij er de stekker uittrekken of onverwachte aanpassingen maken, kan dat zorgen voor het stukgaan van jouw eigen applicatie. Dat is dus iets om even goed bij stil te staan.
 
Danny Spinhuis

Danny Spinhuis

24/03/2018 16:32:44
Quote Anchor link
Dat snap ik, echter heb ik toch gekozen voor de kortere route (de extensie). Nu moet ik dus een aantal voordelige punten benoemen voor mijn keuze, ipv. alleen dat het binnen de scope van het project past. Vandaar dit topic
Gewijzigd op 24/03/2018 16:33:09 door Danny Spinhuis
 
Ozzie PHP

Ozzie PHP

24/03/2018 16:35:25
Quote Anchor link
Het gaat om een schoolopdracht vermoed ik?
 
Danny Spinhuis

Danny Spinhuis

24/03/2018 16:37:31
Quote Anchor link
Ozzie PHP op 24/03/2018 16:35:25:
Het gaat om een schoolopdracht vermoed ik?


Correct
 
Ozzie PHP

Ozzie PHP

24/03/2018 16:41:58
Quote Anchor link
Het grootste voordeel is dan tijd- en kostenbesparing. Besparing van processorkracht lijkt me persoonlijk wat ver gezocht. Er moet verbinding worden gemaakt met een externe server, wat betekent een extra omweg. Een klant ondervindt daar geen voordeel van.

Voor de rest geldt nog steeds wat ik eerder zei. De afhankelijkheid van de externe server, in combinatie met veiligheid. Daar zou je vragen over kunnen krijgen.
 
Danny Spinhuis

Danny Spinhuis

24/03/2018 16:44:05
Quote Anchor link
Ja indd, zoiets zat ik ook aan te denken. Ik hoopte dat er meer voordelen aan gekoppeld konden worden haha. Maar bedankt, ik probeer mn keus zo goed mogelijk te verdedigen.
 
Ozzie PHP

Ozzie PHP

24/03/2018 16:57:41
Quote Anchor link
Ik zou het vooral gooien op kosten en tijd.

Wellicht kun je in je code een check inbouwen die eerst test of de verbinding/service wel beschikbaar is, zodat je een nette foutmelding kunt tonen wanneer de service down is. Je kunt dan tevens een waarschuwingsmailtje naar jezelf laten sturen, zodat je het kunt monitoren.

Ik denk dat je leraar zo'n extra check wel kan waarderen ;-)
 
Thomas van den Heuvel

Thomas van den Heuvel

24/03/2018 17:17:37
Quote Anchor link
Je geeft min of meer zelf aan dat je je in een onhandige positie hebt/bent gemanoeuvreerd. Met de gebruikmaking van een externe tool ben je afhankelijk van die tool geworden. Dit lijkt sterk op een vendor lock-in. In plaats van het halsstarrig zoeken naar positieve punten (die mogelijk met veel moeite op een hand te tellen zijn of er simpelweg niet zijn) zou je ook hard(er) kunnen maken dat er geen (geschikte) alternatieven waren, of dat je simpelweg iets mist (tijd, geld, kennis of een combinatie) wat tot een betere situatie had kunnen leiden. Dit heb je zelf ook al aangegeven, vanwege beperkende randvoorwaarden is dit het best haalbare resultaat binnen die randvoorwaarden. Ook geef je aan dat als je meer tijd had dat je dan mogelijk zelf wel iets had kunnen realiseren zonder daarbij een afhankelijkheid met een andere partij te creëren.

En als dit een stageopdracht is: in mijn tijd was er altijd sprake van een inspanningsverplichting en niet zozeer van een resultaatverplichting. Ook is het volgens mij (nog steeds) niet de bedoeling dat stagiairs rechtstreeks met de "rode-draad-processen" van bedrijven bezig zijn, ook al gebeurt dat in de praktijk helaas vaak wel. Als hier sprake van is?

Je mag (en moet) jezelf ook een beetje indekken en als en onredelijke dingen van jou verwacht worden dan moet je dit ook gewoon aangeven en beargumenteren, waarbij je natuurlijk blijk geeft dat je mee wilt werken aan oplossingen, maar dat men niet kan verwachten dat de bomen tot in de hemel groeien - het is ook jouw verantwoordelijkheid om verwachtingen bij te schaven als deze onrealistisch zijn. Ik weet ook dat het soms lastig is om het... enthousiasme te temperen. Vooral als je van doen hebt met mensen die a-technisch zijn en "niet snappen waarom iets zolang duurt".

Dit onderzoek (wat eigenlijk niet echt een onderzoek is volgens mij?) gaat, zoals ik het begrijp, er dus niet zozeer over of reeds gemaakte producten beter zijn (dat hangt er maar helemaal vanaf, zie vorige antwoorden - hier is op voorhand geen eenduidig antwoord op te geven), maar meer om een onderbouwing/verantwoording voor gemaakte keuzen?
Gewijzigd op 24/03/2018 17:18:36 door Thomas van den Heuvel
 
Danny Spinhuis

Danny Spinhuis

24/03/2018 17:39:28
Quote Anchor link
@Thomas: Het onderzoek is al vrijwel zo goed als af. Er zijn meerdere oplossingen onderzocht, die hetzelfde resultaat geven. Echter was dit de beste keus, omdat deze het meest aansloot op de requirements.

@Ozzie: goed punt, zo'n check is indd wel handig ja! Thanks.

Bedankt voor het meedenken heren!
 
Ozzie PHP

Ozzie PHP

24/03/2018 17:54:15
Quote Anchor link
@Danny

Graag gedaan en succes! Laat t.z.t. even weten hoe het is afgelopen :)
 
Danny Spinhuis

Danny Spinhuis

24/03/2018 18:38:51
Quote Anchor link
Ozzie PHP op 24/03/2018 17:54:15:
@Danny

Graag gedaan en succes! Laat t.z.t. even weten hoe het is afgelopen :)


Doe ik! Thanks
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.