Categorie: Geen categorie

https://roadmap.sh/

Bij Pronamic hebben we als richtlijn dat we alles strict in het Engels programmeren. Stagiairs leren we daarom ook altijd om in het Engels te programmeren. Toch zijn er op internet ook vele voorbeelden te vinden waarin Nederlandse naamgeving wordt gebruikt in de code. Waarom heeft Engels dan bij ons de voorkeur? Ik ben voor de aardigheid eens op zoek gegaan naar goede argumenten. Al snel kwam ik een artikel tegen uit het boek “Het beste van PHP en MySQL“.

Engels of Nederlands

Amerikaans Engels is de voertaal onder programmeurs. Ook de meeste PHP-ontwikkelaars gebruiken Engels. Als je echter PHP-script alleen voor jezelf schrijft of als je in een team met alleen Hollanders en Vlamingen werkt, zijn er goede redenen om Nederlands te gebruiken.

Wanneer je Nederlands gebruikt voor alle namen die je zelf kunt kiezen, wordt broncode beter leesbaar. Het verschillen tussen Engelstalige termen uit PHP en zelfgekozen namen in dan direct zichtbaar. Dat is de reden waarom ik in dit boek vaker Nederlands gebruik dan Engels: het maakt de voorbeelden veel duidelijker als PHP nieuw voor je is.

De kans op naamconflicten neemt drastisch af als je Nederlands gebruikt. Als je Engels gebruikt voor bijvoorbeeld een functie die je zelf definieert, bestaat altijd het risico dat je per ongeluk een bestaande PHP-functie gebruikt. Naamconflicten kunnen ook voorkomen met andere talen die je in PHP gebruikt: HTML, CSS, SQL, HTPT, MIME, XML enzovoort gebruiken allemaal Engels.

Natuurlijk moet je niet overdreven vasthouden aan het Nederlands. Hoewel databank en gegevensbank foutloos Nederlands zijn, zeggen en schrijven ontwikkelaars altijd database. Het Nederlands kent al helemaal geen bruikbaar synoniem van query. In zulke gevallen kun je naamconflicten voorkomen door verschillende woorden of een samenstelling met Nederlands te gebruiken. Maak dan van $database en $query bijvoorbeeld $database_met_producten en $selectiequery.

Ward van der Put

In een boek zoals deze is het denk ik ook prima om Nederlandse code voorbeelden te gebruiken. Lezers kunnen op die manier waarschijnlijk sneller zaken herkennen. Het argument om Nederlands te gebruiken om naamconflicten te voorkomen vind ik wat minder sterk. Voor dat probleem zijn er in PHP denk ik namespaces geïntroduceerd.

Al met al nog niet hele sterke argumenten om wel of niet in het Engels of Nederlands te programmeren. Ik ben daarom verder gaan zoeken en kwam o.a. de volgende vragen / topics tegen:

• Software Engineering Stack Exchange: “Do people in non-English-speaking countries code in English?”
• Quora: “Is it better learning programming in English or in my native language (Portuguese)?”
• DEV Community: “Do you feel comfortable learning in your own language or do you prefer English? (For non English-native speakers)”

Velen geven aan dat Engels de voorkeur heeft, maar om programmeren te leren je moedertaal wel fijn kan zijn.

DomQ (een Fransman) noemde nog wel de volgende aandachtspunten:

• I speak the language that the target audience will most likely understand. When coding open-source software with a global ambition, I use English. For less widely useful stuff (for instance, my Emacs configuration file), I might use French.

• I acknowledge the fact that not everyone will master English. In that perspective, using my mother tongue might actually make my code more accessible instead of less (in the example above, nobody cares about an umpteenth .emacs, except if it happens to be written in a language that they understand).

• Better to write good French than bad English. I actively discourage my subordinates from writing half-assed English especially where concision matters, eg in docstrings and version control commit messages.

https://softwareengineering.stackexchange.com/a/1764

Mattias Kihlström (een Zweed) noemde volgende argumenten om Engels te gebruiken:

• Allmost all programming languages I have ever used have been written in English (mixing languages would make the code harder to read for me)

• Most popular frameworks and third party extension are written in English (again, mixing languages would only be a distraction)

• Swedish characters (åäö) are usually not allowed when naming variables and functions

• If the other team members are from different countries we can still collaborate

• If I need support from a platform vendor it is is much easier for them to help me if they can understand my code

• It is easier to outsource support

https://softwareengineering.stackexchange.com/a/1687

Ik sluit me persoonlijk aan bij de argumenten van Mattias, dat zijn denk ik ook de redenen waarom we bij Pronamic in het Engels programmeren.

Mocht je zelf ook nog goede redenen hebben om in het Engels of juist in het Nederlands te programmeren dan hoor ik ze graag. Laat daarom gerust een reactie achter.

GoAccess is een leuk tooltje voor het analyseren van log bestanden. Voor het analyseren van SiteGround Access Logs kan het volgende commando gebruikt worden.

export LANG=en_US.UTF-8

goaccess -f access.log --log-format='%h %v %^ [%d:%t %^] "%r" %s %b "%R" "%u"'  --date-format='%d/%b/%Y' --time-format='%H:%M:%S'

Voor de nerds 🤓, ASCII kunst met FIGlet en TOIlet:

FIGlet

Er zijn veel FIGlet fonts beschikbaar, deze kun je bekijken via het showfigfonts commando. En op http://www.figlet.org/fontdb.cgi is ook een lijst te vinden van fonts.

TOIlet

TOIlet werkt vergelijkbaar met FIGlet maar heeft coole kleuren filters 🦄🌈.

TOIlet kan ook overweg met FIGlet fonts:

Het subcommando figlet -I 2 geeft de standaard FIGlet font map terug zodat TOIlet weet waar de FIGlet fonts te vinden zijn.

Bronnen

• http://www.figlet.org/
• http://caca.zoy.org/wiki/toilet
• https://www.maketecheasier.com/figlet-and-toilet-asciify-your-text-art/
• https://www.linux.com/learn/linux-tips-fun-figlet-and-toilet-commands
• https://delightlylinux.wordpress.com/2015/11/13/colored-text-with-toilet/

Bij Pronamic maken we binnen WordPress projecten veel gebruik van Composer, PHPUnit en andere tools. Om het aanroepen van scripts te vereenvoudigen maken we ook wel gebruik van Composer scripts. In plaats van bijvoorbeeld vendor/bin/phpunit te typen kunnen we dan composer phpunit gebruiken.

{
	"name": "…",
	"description": "…",
	"config": {
		"sort-packages": true
	},
	"require": {
		"php": ">=5.6.0"
	},
	"require-dev": {
		"phpunit/phpunit": "^5.7"
	},
	"scripts": {
		"phpunit": "vendor/bin/phpunit"
	}
}

Nadeel daarvan was echter dat composer phpunit geen kleuren output gaf. Terwijl het aanroepen van vendor/bin/phpunit wel een kleuren output gaf. Dit terwijl in het PHPUnit configuratie bestand phpunit.xml.dist wel colors="true" stond. Na een kleine zoektocht kwam ik de oorzaak en oplossing tegen op Stack Overflow:

I added --colors=always from PHPUnit master (4.6) branch which did the trick. It seems PHPUnit actually detects it is called through another scripts and suppresses the colors itself.

Haralan Dobrev – https://stackoverflow.com/questions/27024298/keep-color-output-when-running-scripts-on-composer#comment44218731_27024464

{
	"name": "…",
	"description": "…",
	"config": {
		"sort-packages": true
	},
	"require": {
		"php": ">=5.6.0"
	},
	"require-dev": {
		"phpunit/phpunit": "^5.7"
	},
	"scripts": {
		"phpunit": "vendor/bin/phpunit --colors=always"
	}
}

Hoe we dit bij Pronamic in gebruik hebben is bijvoorbeeld te zien in de WordPress pay core bibliotheek:

https://github.com/wp-pay/core

1. 🔎🐠
   Finding Nemo (Op zoek naar Nemo)
2. 🏴‍☠️⚓️🏝
   Pirates of the Caribbean
3. 🐝🐛🐌🐞🐜
   A Bug’s Life
4. 🦁🐗🐘🌅👑
   The Lion King (De Leeuwenkoning)
5. 👹🕯🕑🌹✨👩🏻‍🦰
   Beauty and the Beast (Belle en het Beest)
6. 🐶🍝🐶🎹🎁
   Lady en de Vagebond (Lady and the Tramp)
7. 👾🎮🔨👊🍭🏅
   Wreck-It Ralph
8. 🐠🐚🐟🔱🐙🌊🧜‍♀️
   The Little Mermaid (De kleine zeemeermin)
9. 🐭🎪👂🐘
   Dumbo (Dombo)
10. 👦🏼👴🏻🏠🎈⬆️
    Up
11. ☃️👸😨
    Frozen
12. 🐍🐻🧒📖
    The Jungle Book (Jungle Boek)
13. 📖🤠👢🌵🚀👨‍🚀🍕
    Toy Story
14. 💯1️⃣🐶
    101 Dalmatians (101 Dalmatiërs)
15. 🧞👳‍♂️🕌👩🏻❤️
    Aladdin
16. ❄️🍎💎7️⃣
    Snow White and the Seven Dwarfs (Sneeuwwitje en de zeven dwergen)
17. 🚕⚡️🚗🚙💨🏁⛽
    Cars
18. 👵🏻💇🏼‍♀️🐴🤴🏻🏰
    Tangled (Rapunzel)
19. 👠👗🎀🤴🏻🎃✨
    Cinderella (Assepoester)
20. 👸💋🐸🎶✨
    The Princess and the Frog (De prinses en de kikker)
21. 🦌❄️⛸🐰
    Bambi
22. 🤥🦗👴🏻
    Pinocchio (Pinokkio)
23. 👦🏻🧚‍♀️🏴‍☠️
    Peter Pan
24. 🦊👦🏻🏹🌳
    Robin Hood
25. 🐭🍽🧀👨‍🍳
    Ratatouille

Bron:

Het migreren van WordPress websites kan vaak erg snel gerealiseerd worden met behulp van SSH en enkele commando’s. Hieronder een aantal commando’s die hierbij van pas komen:

rsync --archive --verbose --compress --exclude-from=/data/www/example.com/public_html/.gitignore [email protected]:/home/user/domains/example.com/private_html/ /data/www/example.com/public_html/.

rsync --archive --verbose --compress --rsh='ssh -p 18765' /Users/remco/Downloads/example.com/ [email protected]:/home/user/public_html/.

mysqldump --host=123.456.789.0 --user=user_wp --password=******** --databases db_wp > /data/www/example.com/databases/db_wp.sql

mysql --host=123.456.789.0 --user=user_wp --password=******** mysql --execute="DROP DATABASE db_wp; CREATE DATABASE db_wp;"

mysql --host=123.456.789.0 --user=user_wp --password=******** db_wp < /data/www/example.com/databases/db_wp.sql

find /data/www/example.com/public_html/wp-content/uploads -type d -exec chmod 775 {} \;

find . -type d -exec chmod 755 {} +

curl http://*.s3.amazonaws.com/site.zip --output site.zip

unzip site.zip -d site

Webontwikkelaars die werken met cPanel en Let’s Encrypt zijn ongetwijfeld wel eens de volgende melding tegen gekomen:

There was a problem installing the certificate. Please contact support for more information.

Het kan soms lastig om te achterhalen wat precies het probleem was. Vaak kan de support afdeling van de hostingleverancier je dan verder op weg helpen. Als je SSH-toegang hebt tot het betreffende hosting pakket kun je vaak ook via die weg zelf achterhalen waar het fout gaat. Voordat je binnen cPanel het Let’s Encrypt certificaat installeert maak je dan via SSH verbinding. Vervolgens roep je daar het volgende commando aan:

tail -f ~/.letsencrypt/logs/letsencrypt.log

Op die manier krijg je realtime alle nieuwe logs binnen je terminal te zien. Vervolgens ga je via cPanel het Let’s Encrypt installeren en hou je je terminal in de gaten. Wat ik vaak voorbij zien komen is dat de DNS-records voor de betreffende domeinnaam niet goed zijn ingesteld. In de logs zijn dan vaak de volgende meldingen terug te zien:

example.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://example.com/.well-known/acme-challenge/...

Als WordPress webontwikkelaar bij Pronamic maak ik veel gebruik van de Mac OS schermafbeelding functionaliteit (cmd ⌘ + shift ⇧ + 4 » spatie). Voornamelijk voor blog berichten, support en documentatie doeleinden komt deze functionaliteit goed van pas. Wat ik minder mooi vind is de schaduw rondom schermafbeeldingen van Mac OS applicatie vensters. Na een zoektocht via Google blijkt dit eenvoudig uitgeschakeld te kunnen worden. Door het uitvoeren van de volgende commando in de terminal is dit uit te schakelen:

defaults write com.apple.screencapture disable-shadow -bool true

Hierna zal SystemUIServer herstart moeten worden om de wijziging actief te maken:

killall SystemUIServer

Schermafbeelding met venster schaduw 

Schermafbeelding zonder venster schaduw

Uiteraard kan de schaduw ook weer ingeschakeld worden:

defaults write com.apple.screencapture disable-shadow -bool false

Bron: http://osxdaily.com/2011/05/23/disable-shadow-screen-shots-mac/