User:Dereckson/Blog

Some topics I could blog about. Add a new idea.

Comments

Three level of comments

• The header
• The code documentation
• The comments itself

The header

• Project metadata
• License

The code documentation

• Javadoc (PHP) / XML code (.Net) formats
• There are tools to automate the process (PHPDoc, Sandcastle, Doxygen, etc.)

The comments itself

• Comments aren't paraphrase. You shouldn't rewrite in English what you wrote in code.
• Explain to another people your code. Craft your comment with this explanation.

Credits

Thank you to Nojhan for the tip about explain the code to another people, and put the explanation into a comment.

Wikimedia configuration workflow

Last October, Andre Klapper became the new Bug wrangler of the Wikimedia Foundation.

He asked me to explain him our site requests configuration workflow.

In a nutshell, when a wiki wishes a configuration change, they follow this workflow:

1. discuss the issue on the local wiki
2. report the issue on Bugzilla (normally, they should add the 'shell' keyword as this stage, to indicate an action is required by a sysadmin with shell access)
3. clarify the configuration change if needed
4. the config change is then prepared, reviewed and deployed
5. the bug is closed

Now, more often than not, a user will ask a configuration request or report a bug which is actually a config change without previous discussion. Or the issue has been discusse by 3 people on a huge wiki like en. de. fr.

In these cases, we "block" the configuration change with the shellpolicy keyword.

This is a signal to 3 users groups:

• to the local wiki community in general, the bug requester in particular > "please launch a discussion to get a local consensus"
• to the Wikimedia community at large (but generally there are ops people still in touch with wiki communities or stewards) > "please determine if this small discussion constitutes or not a local consensus"
• to the tech people, "please wait before deploy"

Host a MediaWiki site: low cost solutions

• https://robot.your-server.de/order/market Hetzner Online]
• Linode
• RootBSD
• Johncompanies
• Frantech
• Debibox

• 256 Mb VPS should be enough.
• 128 not really (InnoDB)
• Ideal seems to be 256 burstable to 512

Reading: #!

Sven Mascheck, The #! magic, details about the shebang/hash-bang mechanism on various Unix flavours, http://www.in-ulm.de/~mascheck/various/shebang/

https://gerrit.wikimedia.org/r/#/c/37374/1/wikibugs

A strange instruction

We can read this peculiar piece of instructions in the manual:

You should definitely have latest libpurple, so download Pidgin and compile it, because your distribution probably doesn’t have the latest one.

This is interesting. The developer mixes support instruction for its distro and build instructions!

This is plainly wrong of course. Let's compare two set of dates:

• http://svnweb.freebsd.org/ports/head/net-im/libpurple/Makefile?view=log FreeBSD port Makefile history
• http://hg.pidgin.im/pidgin/main/tags Pidgin tags history

Here the update situation at the exact moment (2012-03-28) of the 2.0.0 beta 2 release:

Version bumped on the Pidgin repository | Version bumped on the FreeBSD ports repository 2.10.2 2012-03-14 2012-03-18 4 days 2.10.3 2012-03-26 2012-04-01 5 days

This is also absolutely not informative. I arbitrarily set >2.10.2 as the required version, but I have no idea of the real required version, as this is not documented.

• Spectrum 2 is a UNIX application, not a application tailored to work only on the Linux distribution of the developer, so this is not really our problem.

https://github.com/hanzz/libtransport/blob/master/docs/guide/from_source_code.textile

Secure poll

https://bugzilla.wikimedia.org/show_bug.cgi?id=43457

MediaWiki - CSS changes

see css bug

Canfranc

Commons:Category:Estación de Canfranc

http://www.trekearth.com/gallery/Europe/Spain/Aragon/Huesca/Canfranc/photo363817.htm

http://www.coloredhome.com/paisajes_pirineo/estacion_de_canfranc/estacion_canfranc.htm