Home

Welcome to the network-weathermap wiki!

I just added a couple of pages to keep track of the current work, especially the Refactoring

Also, some notes on getting a dev environment working.

Finally, I know it's hard to believe, but I try to stick to a few rules for Weathermap code:

1. Really think hard about breaking changes for end-users. Weathermap end-users are typically non-programmer network engineers. They just want working maps that carry on doing the same thing across upgrades.
2. Everything should work on CentOS 6. There's a lot of this out there still, and it comes with PHP 5.1 plus backported security patches.
3. Every new feature has a new test. How else can you tell it's working? And that you didn't break all the other interdependent features?
4. Every new feature has documentation. There's a (hopefully) complete reference manual for all the config keywords in Weathermap. A change in behaviour should be documented in there, including updating the version history for that keyword.
5. Everything should pass PHPCS' PSR2 ruleset. There are some exceptions. Because of #2, there is no namespace. Also, there are methods without camelCase naming, because they are inherited in other people's DS plugins. This one is a work-in-progress (4500 lines of output from PHPCS right now!)
6. Classes and globals should have a WM or WeatherMap prefix. In the Cacti plugin, all of the Weathermap code is included into the Cacti poller - it shouldn't be possible to have namespace clashes.