Ga naar inhoud

Eureka Erlebnis


Roger

Aanbevolen berichten

Het is me al vaker overkomen: Je worstelt al een tijdje met een probleem en je komt er maar niet uit. Je kamt het hele forum uit maar ook dat biedt al niet de gehoopte soelaas. Uiteindelijk besluit je de vraag dan toch maar te posten. En terwijl je je vraag zorgvuldig zit te formuleren komen de gedachtes op en switch je nog een paar keer tussen je webbrowser en je FileMaker. Dit nog eens proberen en dat. En als ik nou eens... of eh... heb ik daar eigenlijk wel aan gedacht? En zou het niet logisch zijn als..., en... en... verrek... wat is dat?? Het werkt!! Ik heb het werkend!! EUREKA!

Ben ik de enige die dit wel eens meemaakt of herken je dit ook? Als er meer mensen zijn die wel eens deze Erlebnis hebben is mijn tip: Formuleer je vraag en formuleer deze zo helder mogelijk. Denk hier goed over na. Ga naar de essentie. Zal de lezer gemakkelijk begrijpen wat je probleem is? (Grote) kans dat als jij je vraag helder hebt en dus goed over je vraagstuk hebt nagedacht, het antwoord al bij je opgekomen is nog voordat je op de 'Vraag plaatsen knop' hebt hoeven drukken. :-)

 

 

 

Link naar reactie

Ja, ik ken het fenomeen, en ik vind het in zekere zin een filosofisch vraagstuk. Het ophelderen in de taal kan problemen oplossen, maar is mi ook altijd beperkt, en kan nieuwe problemen introduceren.

heb je er problemen mee dat mensen je tip niet volgen en hun vraagstukken te lichtvaardig hier posten?

Je zou het ook de essentie van dit forum kunnen noemen om dit cognitieve zoekproces samen aan te gaan. 
 

 

Link naar reactie

Is mij ook wel eens overkomen. Doordat ik FM net te weinig gebruik om met het programmeren ervaren mee te blijven loop ik vaak vast. Vaak is dan de opzet van de database verkeerd. Een aantal keer hier op het forum geholpen, maar een paar keer ook vastgelopen in het goed kunnen opstellen van het probleem om hier hulp te vragen.
Als de vraagstelling dan eindelijk klopt is het probleem van de databaseopzet ook helder.
Daarna loop ik dan soms vast in relaties en formules, maar via een omweg lukt het vaak ook wel. Zullen nooit schoonheidsprijzen mee te halen zijn, maar wel werkende databasesystemen.

Link naar reactie

Het lastige is, dat een geboden oplossing (op dit forum) niet altijd 'past' in de manier waarop je je database in elkaar hebt gestoken, de werkwijze die je je eigen hebt gemaakt. Ik doe bijvoorbeeld heel selecties met relaties en table occurrences (Go to Related Record), maar anderen werken altijd met een Find opdracht. Is een kwestie wat je gewend bent.

Daarom is het ook vaak moeilijk (en niet prettig) om een oplossing van iemand anders over te nemen. Je moet je eerst verplaatsen in de denkwijze van die ander. Het is ook een probleem bij het gezamenlijk werken aan één systeem: de neuzen moeten allemaal dezelfde kant op wijzen. Denk niet dat het beperkt is tot FileMaker alleen: de plugin- en addon-jungle van WordPress is het gevolg van precies dat.

Alle wielen zijn rond, maar meer uit noodzaak dan dat er over nagedacht is.

Link naar reactie

Uit oogpunt van kennisontwikkeling zou het juist leuk moeten zijn om al die diversiteit in ontwikkelkeuzen te ondervinden. Er zijn inderdaad altijd wel meerdere wegen, maar er de ene route is beter dan de ander. Of er dat een goede reden is om A en niet B te kiezen. 
 

Maar ik begrijp ook wel dat dit een vermoeiend proces kan zijn. Toch ben ik van mening dat een goede developer methodisch gezien op een soort meta-niveau moet kunnen/willen opereren: een bepaalde weg kiest terwijl hij alle mogelijke benaderingen overziet. 

Het punt van Roger is dat je soms niet eens toegevoegde kennis nodig hebt om een oplossing te vinden voor een gegeven probleem. Verhelderen en herdefiniëren/formuleren van het probleem volstaat. Denk dat dat zonder meer waar is.

 

 

Link naar reactie

Ja daar ben ik het helemaal mee eens, de oplossing vind je heel vaak door jouw probleem zo duidelijk mogelijk te definiëren.

Je kan echter een standaard-functie of het gebruik ervan niet kennen en dan is een vraag stellen op een forum wel nodig. Alleen een goede probleemdefinitie is dan niet voldoende.

 

Link naar reactie
  • 2 weken later...
Op 23/01/2021 om 11:16 zei hans erik:

Daarom is het ook vaak moeilijk (en niet prettig) om een oplossing van iemand anders over te nemen........

Toch kan ik je vertellen dat ik als niet programmeur al menige oplossing heb gevonden door een oplossing van iemand anders te doorgronden en toe te passen op iets waarbij ik zelf geen oplossing kon vinden. Het helpt je vaak te denken vanuit een andere hoek en je inzicht te vergroten. Natuurlijk voelt het soms wel als afkijken of na-apen, maar dat is alleen de eerste keer dat je de oplossing gebruikt. Ik ervaar de aangeboden oplossingen als zeer prettig, al snap ik er heel vaak op dat moment nog niet echt veel van. Maar voor dat je het weet gebruik je die manier van denken bij andere situaties en vind je alsnog de juiste oplossing.

Link naar reactie

Natuurlijk en dat is ook mooi (en logisch). Ik heb niks tegen na-apen: beter goed gekopieerd dan slecht bedacht. Deze industrie is voor 80% gebaseerd op na-apen.

Maar als er twee of meer programmeurs aan een systeem werken met elk hun eigen 'methode' zijn er al gauw meerdere stuurlui op hetzelfde schip en dat pakt niet altijd goed uit (ik spreek uit ervaring).

Link naar reactie
1 uur geleden zei bigbadwolf:

Als dat zo is dan is het altijd zaak goede afspraken te maken hoe je bepaalde zaken aanpakt.

Mee eens, maar dat is niet zomaar even gedaan, maar is een proces dat over langere tijd loopt. Om een voorzetje te geven hieronder een (absoluut NIET volledige) lijstje met zaken waar je afspraken over zou moeten maken:

  1. Normalisatie, Roger noemde het ook al. Zie: https://nl.wikipedia.org/wiki/Databasenormalisatie

  2. Naamgeving van basetables, columns, table-occurences, functions, scripts, etc. Zie wikipedia over naming-conventions: https://en.wikipedia.org/wiki/Naming_convention_(programming) en bijvoorbeeld specifiek op FileMaker toegespitst deze discussie: https://filemakerstandards.org/display/cs/Naming+Conventions

  3. Documentatie in scripts, veld-definities, db-schema, custom-functions, op lay-outs etc. 

  4. Algemene werkwijze in scripts: procedureel of in semi-objecten

  5. Binnen calculaties en scripts parameters declareren (naamgeving, global, local) separaat, geclusterd etc.

  6. Parameters tussen scripts en bestanden uit te wisselen, via globals, in scriptparameters, via velden etc.

  7. Knopdefinities: maak je algemene scripts en geef je (veel) parameters mee, maak je voor iedere knop een apart script of werk je met een hybride vorm.

  8. Lay-outs, hoe zien de objecten er uit. Dus eigenlijk gaat dit over thema-integratie, want het is wél zo fijn dat alles er eenduidig uitziet.

  9. Security, want je wil niet dat mensen zomaar records gaan wissen/wijzigen of zonder enige samenhang gaan toevoegen

  10. Custom functions, wanneer maak je er een, waarom, autonoom, etc.

Mijn ervaring is dat dit helemaal niet zo simpel is en dat je heel snel een enorm boekwerk met regels maakt. Soms is dat heel handig, maar het kan ook een blok aan je been worden. Voor je het weet ben je bezig met randzaken die er voor sommige doelen helemaal niet toe doen. Het voldoen aan de regeltjes wordt dan belangrijker dan het werk uitvoeren en daar kennen we allemaal wel voorbeelden van.

Ik doe meestal mijn best om het werken en denken van de mensen waar ik mee samenwerk, zo goed mogelijk te doorgronden en daar dan voor een deel in mee te gaan. Enkele van mijn eigen methoden integreer ik dan weer in hun werkwijze en van lievelee assimileren we de verschillende manieren van zaken oplossen. Ieder kan zo zijn eigen manier van werken grotendeels behouden en we begrijpen elkaar meestal prima.

"Specialisme" onstaat er toch wel en zolang je maar documenteert wat je doet, komt een ander daar best uit. Kan je dan even niet iets dat jij hebt gebouwd oplossen, dan kan een ander dat meestal zonder grote problemen overnemen. Het wordt alleen problematisch wanneer mensen nergens commentaar bij schrijven en dat gaat lang niet altijd over de code. Het is ook heel handig om iets over de "Business rules" vast te leggen.

Ik kom bijvoorbeeld soms facturatie-routines tegen, waar in een hulp-tabel van alles wordt geïmporteerd en dan deels gewist en in een andere tabel worden dan allerlei gegevens aangepast, terwijl de veldnamen dan super-cryptisch zijn en er geen letter commentaar in de scripts en de velddefinities staan. Zolang alles werkt zoals de klant verwacht en de klant ook geen wijzigingen wil, is er niks aan de hand, maar owee als er iets fout gaat of er iets moet worden aangepast. In die gevallen ben ik een veel minder blij mens 🤯

Link naar reactie

Geweldige opsomming van Menno.

Ik zou hieraan willen toevoegen dat het belang van de keuzen die je hier maakt ook geheel voor de eenzame developer geldt, dus nog los van samenwerkingsituaties. Of misschien beter gezegd: een mens moet ook met zich zelf samenwerken. :-)

Parallel dan wel seriëel.

Op 03/02/2021 om 14:55 zei menno:

Mee eens, maar dat is niet zomaar even gedaan, maar is een proces dat over langere tijd loopt. Om een voorzetje te geven hieronder een (absoluut NIET volledige) lijstje met zaken waar je afspraken over zou moeten maken:

  1. Normalisatie, Roger noemde het ook al. Zie: https://nl.wikipedia.org/wiki/Databasenormalisatie

  2. Naamgeving van basetables, columns, table-occurences, functions, scripts, etc. Zie wikipedia over naming-conventions: https://en.wikipedia.org/wiki/Naming_convention_(programming) en bijvoorbeeld specifiek op FileMaker toegespitst deze discussie: https://filemakerstandards.org/display/cs/Naming+Conventions

  3. Documentatie in scripts, veld-definities, db-schema, custom-functions, op lay-outs etc. 

  4. Algemene werkwijze in scripts: procedureel of in semi-objecten

  5. Binnen calculaties en scripts parameters declareren (naamgeving, global, local) separaat, geclusterd etc.

  6. Parameters tussen scripts en bestanden uit te wisselen, via globals, in scriptparameters, via velden etc.

  7. Knopdefinities: maak je algemene scripts en geef je (veel) parameters mee, maak je voor iedere knop een apart script of werk je met een hybride vorm.

  8. Lay-outs, hoe zien de objecten er uit. Dus eigenlijk gaat dit over thema-integratie, want het is wél zo fijn dat alles er eenduidig uitziet.

  9. Security, want je wil niet dat mensen zomaar records gaan wissen/wijzigen of zonder enige samenhang gaan toevoegen

  10. Custom functions, wanneer maak je er een, waarom, autonoom, etc.

Mijn ervaring is dat dit helemaal niet zo simpel is en dat je heel snel een enorm boekwerk met regels maakt. Soms is dat heel handig, maar het kan ook een blok aan je been worden. Voor je het weet ben je bezig met randzaken die er voor sommige doelen helemaal niet toe doen. Het voldoen aan de regeltjes wordt dan belangrijker dan het werk uitvoeren en daar kennen we allemaal wel voorbeelden van.

Ik doe meestal mijn best om het werken en denken van de mensen waar ik mee samenwerk, zo goed mogelijk te doorgronden en daar dan voor een deel in mee te gaan. Enkele van mijn eigen methoden integreer ik dan weer in hun werkwijze en van lievelee assimileren we de verschillende manieren van zaken oplossen. Ieder kan zo zijn eigen manier van werken grotendeels behouden en we begrijpen elkaar meestal prima.

"Specialisme" onstaat er toch wel en zolang je maar documenteert wat je doet, komt een ander daar best uit. Kan je dan even niet iets dat jij hebt gebouwd oplossen, dan kan een ander dat meestal zonder grote problemen overnemen. Het wordt alleen problematisch wanneer mensen nergens commentaar bij schrijven en dat gaat lang niet altijd over de code. Het is ook heel handig om iets over de "Business rules" vast te leggen.

Ik kom bijvoorbeeld soms facturatie-routines tegen, waar in een hulp-tabel van alles wordt geïmporteerd en dan deels gewist en in een andere tabel worden dan allerlei gegevens aangepast, terwijl de veldnamen dan super-cryptisch zijn en er geen letter commentaar in de scripts en de velddefinities staan. Zolang alles werkt zoals de klant verwacht en de klant ook geen wijzigingen wil, is er niks aan de hand, maar owee als er iets fout gaat of er iets moet worden aangepast. In die gevallen ben ik een veel minder blij mens 🤯

Link naar reactie
13 minuten geleden zei Marsau:

een mens moet ook met zich zelf samenwerken. :-)

Ja, daar zeg je zo wat. Af en toe kom ik oude meuk van mezelf tegen, waar ik dan eens geen commentaar bij heb geschreven. Dan kan ik die **kel wel een schop voor zijn ***len verkopen, omdat ik dan weer moet bedenken wat ik toendertijd heb bedacht..... Pijnlijk

Link naar reactie
  • 2 weken later...

Auw.

Wel een mooie lijst, al zie ik bij die Naming Conventions al meteen een paar dingen staan waar ik acuut de kriebels van krijg. Wanneer stoppen we nou eens met ~ (tilde) in namen?? Dat gaat echt niet goed hoor, in de boze buitenwereld. Ook met het oog op onze Europese buren: beperk je alsjeblieft tot a>z, A>Z, 0>9 en de _. En dan mag daar voor namen van scripts en layouts nog de spatie en de - bij maar dan houdt het voor mij daarmee op. Echt: het scheelt op termijn zo ontzettend veel geklieder met quotes en escapes...

Nog een tip: maak in een hoekje van je database schema een lijstje met table occurrences van elke tabel, bivj met de naam a_xxxx waarin xxxx de naam vd tabel is (zonder spaties). Die TOC gebruik je daarna in executeSQL. Dan kun je naar hartelust je schema ondersteboven keren zonder dat je SQL uit de rails loopt.

aangepast door hans erik
Link naar reactie

Doe mee aan dit gesprek

Je kunt dit nu plaatsen en later registreren. Indien je reeds een account hebt, log dan nu in om het bericht te plaatsen met je account.

Gast
Antwoord op deze discussie...

×   Geplakt als verrijkte tekst.   Plak in plaats daarvan als platte tekst

  Er zijn maximaal 75 emoji toegestaan.

×   Je link werd automatisch ingevoegd.   Tonen als normale link

×   Je vorige inhoud werd hersteld.   Leeg de tekstverwerker

×   Je kunt afbeeldingen niet direct plakken. Upload of voeg afbeeldingen vanaf een URL in

×
×
  • Nieuwe aanmaken...