http://hissa.nist.gov/HHRFdata/Artifacts/ITLdoc/235/sttoc.htm
http://checkstyle.sourceforge.net/index.html
Monday, April 20, 2009
Testing with complexity bookmarks:
Posted by
Roman G.
at
11:51 PM
0
comments
Labels: concepts, Language comparison, reading
Sunday, April 19, 2009
Code reviews and luck of requirements
Code reviews with absence of requirements can not provide quality of software themself.
consider example of change:
main()
{
...
--- return ret;
+++ return 0;
}
If this code is ok?
It depends only from requirements.
The code is ok, if the code satisfied requirements, and not ok, if not.
Syntactic correctness actually tells nothing.
Posted by
Roman G.
at
11:04 PM
0
comments
Labels: analysis, concepts, Language comparison
Sunday, December 14, 2008
current notes on net-snmp MIBs
Go watch them online there:
http://www.net-snmp.org/docs/mibs/
Or simply snmptranslate through shell after installing snmp-tools:
# snmptranslate -Tp SNMPv2-MIB::snmpMIB
+--snmpMIB(1)
|
+--snmpMIBObjects(1)
| |
| +--snmpTrap(4)
| | |
| | +-- ---N ObjID snmpTrapOID(1)
| | +-- ---N ObjID snmpTrapEnterprise(3)
| |
| +--snmpTraps(5)
| | |
| | +--coldStart(1)
| | +--warmStart(2)
| | +--linkDown(3)
| | +--linkUp(4)
| | +--authenticationFailure(5)
| |
| +--snmpSet(6)
| |
| +-- -RW- INTEGER snmpSetSerialNo(1)
| Textual Convention: TestAndIncr
| Range: 0..2147483647
|
+--snmpMIBConformance(2)
|
+--snmpMIBCompliances(1)
| |
| +--snmpBasicCompliance(2)
| +--snmpBasicComplianceRev2(3)
|
+--snmpMIBGroups(2)
|
+--snmpSetGroup(5)
+--systemGroup(6)
+--snmpBasicNotificationsGroup(7)
+--snmpGroup(8)
+--snmpCommunityGroup(9)
+--snmpObsoleteGroup(10)
+--snmpWarmStartNotificationGroup(11)
+--snmpNotificationGroup(12)
http://www.net-snmp.org/wiki/index.php/TUT:Writing_a_MIB_Module
Thursday, August 14, 2008
Cygwin pthreads exit causes access violation example
Example of stack overflow in cygwin.
While researched linking and AIX portability, tried example from there:
http://www.ibm.com/developerworks/aix/library/au-gnu.html?S_TACT=105AGX99&S_CMP=CP
(it is erroneous; simple mistakes were fixed):
After exit on cygwin it warns with access violation.
Executable than blocked (for removal).
Posted by
Roman G.
at
1:13 AM
0
comments
Labels: AIX, C, concepts, GNU/Linux, Language comparison, performance
Tuesday, July 8, 2008
c99 vectors, c++ example.
C99 vectors example .c file.
vector's some, and way to view as int's (through union).
C++ references as class members (with initialization, that should be done ), static counter of objects, array, and copy constructor (have to be?) .cpp file.
Posted by
Roman G.
at
2:07 AM
0
comments
Labels: C, C++, C99, concepts, Language comparison
Wednesday, May 21, 2008
Are there in this world any examples of successful usage of GPL in business?
Do you know any examples of successful usage of GPL in business?
Seeking an example of building business on writing GPL software.
I have tried to google model for making money from open source.
There several models for making money from open source that is already written listened,
and some models for making money from writing open source software.
However it seems that it is easier to get money from existing open source than from your own (written by yourself).
There are methods to get money for developer in short, that were found.
(Actually it is very hard to get opinion of person who really makes money, however there are a lot of speculations from people who got from there work for community zero, just dreaming about money from open source. Following are just opinion of people involved in different discussions in Net).
1) Banners Advertisement.
Very simple - put ads on your web-site. Users who have no direct goal when visiting your site, that hosts the software. Very old and easy model. One issue: Why software than?
It seems that it is better to write about housekeeping and Britney new friend, and have much more stupid visitors that have no exact goal (to download your software in the case).
2) Support.
Write software, and somebody will pay you to describe how to work with it and keep it working on servers. Examples of companies : RedHat, JBoss. However, RedHat doesn't write software. RedHat just integrates modules in distro and provide support. Actually it sells risks, due to QoS statement.
JBoss was GPL project, and was bought by Sun. Actually I don't know who got money, and are all code contributors were payed.
MySQL and TrollTech examples, actually represent dual-licensing models (free for free development, and payed for commercial). This case is of:
3rd) Use free version as advertisement and as testing platform for your non-free version.
4) Develop free for one platform (actually testing), and got support from hardware vendors for another platforms. This is example of Linux kernel.
The tool and application you developing that way have actually to represent more value for hardware vendor than other open-source projects in queue for sharing budget of the vendor for such projects.
No warranty that your effort will be payed at all.
However, from my experience (and with my estimate), if you write something that was helpful for solving your tasks, and published it in user-friendly and easy to use form, it will be used by somebody else with 95% of probability. But they will pay you with 95% of probability nothing for your effort.
5) Develop proprietary software using existing LGPL, BSD, MIT code.
And again it is not about writing the open source, and just about reusing existing for making your own NON-GPL business.
I found no example in the real world were GPL license were better that some else (don't consider dual-licensing model, it has issues like mentioned under the link).
Posted by
Roman G.
at
9:15 AM
1 comments
Labels: concepts
Monday, May 19, 2008
rcs + rsync for keeping your files on several machines
I have two GNU/Linux laptops (Xubuntu) and one GNU/Linux desktop (CentOS).
Need to synchronize them to keep the integrity of the information on the machines.
Tried git, but found it too strong too keep my little docs and code snippets.
That way decided to use well known and stable GNU tools rcs and rsync.man rcs
are prerequisites ;
man rsync
Why rcs? Because repository could be synced with code/docs, and it is GNU.
Why rsync? It is GNU solution for syncing files.
Two basic session snippets for usage:
init files for directory:
cd fldr_for_sync
mkdir RCS
# --
rcs -i file # add new file under rcs
# -- it is the same with --
touch another_file; ci anoter_file
basic rsync dir with subdirs; it is not overwrites old files in dest dir;
permissions and links kept;
rsync -avz path_to_fldr_src path_to_dest
I found that rcs + sync can substitute git for such task and even make the task more clear and robust, due to the long history and high stability of the rcs and rsync tools.
Posted by
Roman G.
at
9:44 AM
0
comments
Labels: attributes, CentOS, concepts, eee pc, eeeXubuntu, GNU/Linux, hardware, shell, Ubuntu
GUI vs. Command Line, similiarity in tools
My first long-term job was Unix programming (in despite of fact that first money for code I got for Z-80 chip programming (some little hack of Z80 in beginning of 90'th )).
Thats way I prefer the command line tools.
I think GUI does not have real performance in tasks of programmer, also GUI skills can not be reused when you need automate your task you done before by clicking.
If you typed instead, you can put your typing in the script and make the script working for any count of times.
However I found in my practice some cases when GUI was better than command line for development.
1) Development of GUI
I have experience of the development of tools for the internet trading, that were mouse based and highly interactive. And visual tools for visual development were really much progress in comparison to writing code for forms definition. In such RAD tools for the GUI, GUI interface and the visual development environment is the must.
However, I know that for experienced traders command line tools were much more comfortable.
They used command line tools for trading instead of GUI, if they had the choice.
2) GUI for understanding new tool.
Visual GUI wrapper around CLI can be helpful when you are learning new tool.
Of cause output/actions log window in the CLI form is the must, to be able than do the actions from the command line.
3) GUI as wrapper around family of CLI tools, that are based on some concept, however using different syntax. For example, uniform interface around sccs/rcs/cvs/svn/git/ and so on,
helps you to avoid switching contest errors, when you have to maintain systems, based on different version control tools.
However, CLI wrapper would be even more helpful :)
Posted by
Roman G.
at
8:41 AM
0
comments
Labels: concepts, GNU/Linux, Language comparison, usability