I am very new to Zabbix and am having to navigate it for some work. I want to change when I get notified about low disk space. I have done some research and found a potential expression:
{hostname.vfs.fs.size[h;pfree].last(0)}<5.
However, I have no configuration tab in the top left corner to implement this. I cannot seem to find a place to actually push this expression into.
I have Googled the problem but have not come across a missing configuration or solution in the results :(
I am sure I am navigating it incorrectly or am doing something silly. Any advice would be greatly appreciated.
Zabbix is version 3.2
If you do not have the top "Configuration" menu, it indicates that you do not have sufficient permissions to change the trigger expression.
If you installed this instance of Zabbix, log in as the default "Admin" user. If somebody else installed it, contact that person to obtain the needed permissions or make the configuration changes.
Hi guys I am constructing a task distribution management system for my team in which I want to add a functionality that:
When I create a task, I will have an option to choose "how long is this task valid for being taken". For example, when creating the task I put "2 hours" in the
<input id="valid-for">
, then this task will only be displayed on the dashboard for 2 hours from the time it was created and then after 2 hours -> "display: none".
I've searched the web for the mechanism of achieving this feature but I didn't get a satisfied answer probably because I don't know the right terminology to google. I tried to use AJAX and use TIME_STAMP type attribute in MySQL but didn't know how to proceed. Could anybody tell me how to achieve this feature by the use of MySQL, jQuery or any other technics that could fulfill this feature? No code necessary I just need some explanation.
Thanks guys!
Without knowing any more details, here is how I would consider writing the code:
In the database, have a start time and a use-by time.
In your browser page, you can run a script periodically, say every minute (this is called polling). In this case, you can use Ajax to call back to the server for updates.
At the server end, check for new tasks as well as expired tasks. Then send the results back to the Ajax caller.
Back at the browser, update the dashboard accordingly.
I would be inclined to remove the task on the browser rather than simply hide it.
I am using PHPStorm 9.
I have installed PHPCS to sniff my code. It is properly configured, up and running.
I am working on a very old project, which was implemented in plain PHP, and not using any code standard.
As a result, every time I open any of those files, I get a message at the top of the screen saying that I have too many errors (code style errors).
I have a couple of problems with that.
First, I already know how bad the code is, so I don't need PHP Storm to tell me that all the time.
Second. That message appears and disappears every time I edit the code. As a result, the window editor is constantly moving up and down, which I find specially annoying.
Also, at the top of the screen it is showing me the breadcrumbs, to tell me where I am. I appreciate the help, but I don't actually need it.
So the question is, how can I configure the IDE to disable those two messages? (read arrow and orange arrow in the attached image).
Please notice that I don't want to disable PHPCS. I only want to turn off those annoying messages.
I was unable to find it out by myself because I don't even know how those messages are called. Certainly not 'popups', nor 'status bar'
Best regards
Nicolas
Answering my own questions, thanks to the help of the PHPStorm Support team, Vladimir Luchansky (perhaps you need to create an account to see the thread):
To disable breadcrumbs: Go to File->Settings->Editor->General->Appearance, and untick the option Show HTML Breadcrumbs. Then restart the IDE
To disable the PHPCS messages without disabling PHPCS itself: Well, that option is not available in PHPStorm 9. It will be available for a future release. According to Vladimir, a developer is working on it. In order to make this request to go up in the future request list, the request needs to get as much 'votes' as possible. So, if you are interested in this feature to be ready ASAP, please vote up here.
Best,
Nicolas
I don't believe there's any mechanism for suppressing those phpcs: Too many messages per file alerts. As an alternative solution, you could give this work-around a try:
Clone your current inspection profile via Preferences > Editor > Inspections. Name the new one "Strict (with phpcs)". Then, choose your old inspection profile from the Profile: dropdown box (thus, reverting your project's default inspection profile to your old one). Rename it to "Weak (without phpcs)" and disable phpcs for that particular profile by unchecking the PHP > PHP Code Sniffer validation option.
From this point forward, phpcs inspections (and related alerts, like the one you're concerned about) won't come into play as you're editing your files. However, whenever you do want to inspect one of your files using PHP Code Sniffer, you can do so easily via Code > Inspect Code > Inspection Profile > Strict (with phpcs)
Hope this helps!
I've got lots of source code files written in various languages, but none of them have a standard comment at the top (sometimes even across the same project). Some of them don't have any header comment at all :-)
I've been thinking about creating a standard template that I can use at the top of my source files, and was wondering what fields I should include.
I know I want to include my name and a short description of what the file contains/does. Should I also include the date created? The date last modified? The programmer who last modified the file? What other fields have you found to be useful?
Any tips and comments welcome.
Thanks,
Cameron
This seems to be a dying practice.
Some people here on StackOverflow are against code comments altogether (reasoning that code should be written to be self explanatory) While I wouldn't go that far, some of the points of the anti-comment crowd make sense, such as the fact that comments tend to be out of date.
Header blocks of comments suffer from these symptoms even more so. Every organization I've been with that has had these header blocks, they are out of date. They have a author name of some guy who doesnt even work there any more, a description that does not match the code at all (assuming it ever did) and a last modified date, that once compared with version control history, seems to have missed its last dozen updates.
In my personal opinion, keep comments close to the code. If you want to know purpose of, and/or history of, a code file, use your version control system.
Date created, date modified and author who last changed the file should be stored in your source control software.
I usually put:
The main purpose of the file and things within the file.
The project/module the file belongs to.
The license associated with the file (and a LICENSE file in the project root).
Who is responsible for the file (either the team, person, or both)
Back in 2002, when I was straight out of college and jobs were few and far between after the dot-com bust, I joined a service company which used to create software customized for their clients in Java. I had to sit in the office of a client (which was a ramshackle room in an electric sub-station rigged with an AC to keep the servers running), sharing chairs/PCs with other guys in the team. The other engineers (if I can call them engineers ;) in the group used to make changes ad-hoc to the source code, compile the files and put them into production.
No way to figure out who made what change.
No way to figure out why any change was made.
No way to go to previous version of code, unless the engineer "remembered" what he modified.
Backup: Copy over files from the production server, which were replaced with new files.
Location of backup: Home directory of engineer copying over files to production server.
Reports of production servers going down due to botched attempts of copying over files to the server (missed a file to be copied over, backups getting lost or wrong files being copied over or not all files being copied over) were met with shrugs (oh no, is it down? let's see what happened; hey who changed what recently...? ummm...).
During those days, after spending several frustrating days trying to figure out the whos and whys behind the code, I had devised a system for comments in a list in the header of the source file which detailed the following:
Date of change made
Who made the change
Why was the change made
Two months later when the list threatened to challenge the size of the source code in the file, the manager had the bright idea of getting a source version control system.
I have never needed to put any comments in headers of source files (except for copyright notices) in any company I worked since. In my current company, everything else is mostly self-evident by looking at the code, or going to the bug reporting system which is integrated with the source version control system.
What fields do you need? If you have to ask whether to put some info there, you don't really need that info. Unless you are forced, by some bureaucratic incompetence of your employer, I don't see why you should go looking for more info than you already feel should be there.\
In most organizations, all source files have to begin with a legal blurb. If you're really lucky, it's just a one-liner, but in most cases it's a really long block of legalese. As a result, few people ever read these. Our eye just travels to the first program element and then goes up to its documentation.
So if you want to write anything, write it in association with the topmost program element, not the file.
Any other bookkeeping information should generally be part of your version control, not maintained (poorly) in the file itself.
In addition to the comment above stating license, the project that it belongs to, etc I also tend to put the "weird" requirements at the top as well (such as "built with version X of library Y") so you, or the person who picks it up after you won't change something that the program relies on without realizing it (or, if they do, they will at least know what to change back)
A lot depends on whether you're using an auto-documentation generation tool or not.
While I agree with many of the comments, if you're using JavaDoc or some other documentation generating tool that depends on comments, you'll obviously need to include the things it wants to see.
You did not mention that you are using a version control system and your comment in Neil N's answer confirms this for your older code. While using version control is the best way to go I also have experienced many situations where the cost of doing so for older code would not be paid for by the project's sponsor. If you do not have a centralized change history for the project then the change history can be put in the modules. It is good that you are using a version control system for your new code.
Your company name
All rights reserved (c) year - or reference to appropriate license
Project or library this file is for
Module it belongs to
Description of what it contains
History
-------
01/08/2010 - Programmer - version
Initial creation.
01/09/2010 - Programmer - version
Change description.
01/10/2010 - Programmer - version
Change description.
Those useful fields that you mentioned are good ones. Who modified the file and when.
Your version control software should allow for the embedding of keywords within comments. For example, in CVS, the $Id$ will resolve to the file, date/time modified, and user that modified the file. It will automatically be kept up to date with each check-in.
Include the following information:
What this file is for. That's a very useful piece of knowledge and it's more important than anything else. You should tell the reader, why there is such a file, why did you group functions in a separate file/package/module and why they are used. Maybe briefly, one or two lines, but that should be there.
Legal stuff, if appplicant.
Leave the place for special commands of console editors, such as of Emacs.
Add special commands that your auto-documenting system requires.
Things things you shouldn not include are
Who created the file
When it was created
Who modified it the last time
When it was last modified
What was added by the latest modification
You can--and should--retrieve it via the version control system, where it's constantly and automatically kept up-to-date. Let alone that most of these points are just useless.
Who created the file
When it was created
Who modified it the last time
When it was last modified
What was added by the latest modification
In a Win32 environment, you can use the GetLastInputInfo API call in Microsoft documentation. Basically, this method returns the last tick that corresponds with when the user last provided input, and you have to compare that to the current tick to determine how long ago that was.
Xavi23cr has a good example for C# at codeproject.
Any suggestions for other environments?
As for Linux, I know that Pidgin has to determine idle time to change your status to away after a certain amount of time. You might open the source and see if you can find the code that does what you need it to do.
You seem to have answered your own question there Nathan ;-)
"GetLastInputInfo" is the way to go.
One trick is that if your application is running on the desktop, and the user connects to a virtual machine, then GetLastInputInfo will report no activity (since there is no activity on the host machine).
This can be different to the behaviour you want, depending on how you wish to apply the user input.